Облако, "Turbo"-режим генетической оптимизации
Такое лучше делать не погружая пользователя в нюансы про 2 %. Не надо его заморачивать выбором. Просто сделать и всё.
Это у тебя эмоции говорят. Облако сделано нормально. Нормально значит оптимально по соотношению цена/качество.
Можно вообще дубли заданий сразу выдавать на все 100% заданий, тогда вероятность сбоев упадёт. А ещё можно втрое больше выдавать. Тогда результаты соотносить как два из трёх сходится знать правильный результ.
Но какова эффективность этих решений??? риторика.
ЗЫ ну а если уже предлагать, то можно сделать так:
если осталось 2% заданий, то стартовать следующий раунд без них а эти задания включить как довесок в стартующий тур. думаю генетика от этого практически не пострадает, ведь распределение бедов случайно. В среднем алгоритм вытянет, хотя случайность поиска (неодинаковость в разных запусках) чуть подскочит.
ЗЗЫ Отписал, а потом дочитал твою портянку, практически тоже самое, по русски "у дураков мысли сходятся", у англичан "великие умы мыслят одинаково" :о)
Это у тебя эмоции говорят. Облако сделано нормально. Нормально значит оптимально по соотношению цена/качество.
Нет, не нужно останавливать такие порывы. Без них облако не будет развиваться, а его текущая оптимальность - это не факт.
Предлагаю на обсуждение общественности, если в целом одобрямс - буду отправлять маляву в сервисдеск.
Я бы делал для ГА такую надбавку принудительно.
А на галочку MQ не пойдут.
Я бы делал для ГА такую надбавку принудительно.
А на галочку MQ не пойдут.
Не надо галочку.
Добавить в общий список режимов ещё один (например после [Быстрая (генетический алгоритм)] - [Турбо (ускоренный генетический алгоритм)]).
Мы не используем агрессивный детект, чтобы не тратить лишние деньги пользователей, но для генетики еще раз все проверим и включим более скорую реакцию на на определение тормозных агентов.
Дело в том, что у нас и так работает адаптивный механизм досылки копий заданий при обнаружении тормозов. Это можно заметить по логам, где пишется "получен результат, рассчитанный ранее". Вообще в последовательных переборах тормозные агенты нивелируются, но в генетике с короткими циклами не всегда получается.
Не нужно досылать копии по факту обнаружения "непросчёта" - это всё равно тормоза как минимум вдвое. Нужно генерить избыточное количество заданий с самого начала, и при наборе необходимого числа просчётов генерить новую популяцию.
Дело же не только в тормозных агентах - часть вполне скорострельных просто выпадают из облака в процессе расчёта по разным причинам. Это и нужно компенсировать избыточностью.
Вот как раз методом избыточной генерации и можно избежать рантайм-отслеживание выпадения агентов, только по факту возвращения решений - этого достаточно.
Прикол в том, что избыточность нужна микроскопическая - 1-3%, в среднем 2%.
Прикол в том, что избыточность нужна микроскопическая - 1-3%, в среднем 2%.
Это в конце видно, что надо было 2%. А во время старта никак не известно, какие именно 2% из 100% запускать заведомо сразу.
В любом случае, будем думать над улучшением.
Это в конце видно, что надо было 2%. А во время старта никак не известно, какие именно 2% из 100% запускать заведомо сразу.
В любом случае, будем думать над улучшением.
Ренат, возможно Вы не совсем уловили идею. Нужно запускать 102% уникальных заданий, а вовсе не 100% уникальных + 2% дублей.
Дубли не нужны в принципе. Все задания данного конкретного поколения статистически равноценны.
Поэтому неважно какие именно 100% необходимые для следующего поколения будут вовремя возвращены - остальные 2% можно не ждать.
Это в конце видно, что надо было 2%. А во время старта никак не известно, какие именно 2% из 100% запускать заведомо сразу.
В любом случае, будем думать над улучшением.
Речь не о первой эпохе, подвисшие задания тормозят запуск второй итд эпох, вот этого момента и касается предложение.
Старт последующей эпохи не дожидаясь окончания 2% тормозных ядер (с выдачей этих заданий на новую эпоху).
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Потратил вчера десяток баксов на оптимизацию в облаке. То что хотел проверить - проверил, НО.....
Осталось ужасное впечатление от работы генетического алгоритма. Примерно 98% заданий в каждом поколении выполняются в бодреньком темпе, а оставшиеся 2% зависают в ожидании, отъедая примерно 50% (!!) времени.
Природа этой задержки вполне понятна:
Предлагаю простой метод ликвидации этой задержки, для пользователей облака, согласных переплачивать 2% денег за двухкратное повышение скорости оптимизации.
Для этого необходимо и достаточно на каждом этапе оптимизации (в каждом поколении) генерировать и отдавать облачным агентам на два процента больше заданий чем требуется (т.е. 102%). При получении 100% решений (оставшиеся два процента отбрасаваются) генерировать новое поколение и запускать в облако новые задания.
Никакого ухудшения качества оптимизации не произойдёт, это можно математически обосновать.
Понятно, что делать такой режим основным не стоит, ибо часть отброшенных заданий таки будет облаком завершено (не все, конечно), следовательно они должны быть оплачены юзером. Понятно, что юзер платить за неиспользованные решения не обязан. Отсюда вывод - режим должен быть опциональным. В хелпе должно быть пояснение принципа работы ускоренной технологии и предупреждение о дополнительной оплате.
---
Собсно всё. Есть ещё "бесплатный" вариант (который я юзаю в своём оптимизаторе). Суть принципа в том, что можно не отбрасывать "опоздавшие" решения, а использовать их в следующих поколениях на общих основаниях. Эмпирически обнаружено, что эффективность алгоритма при этом практически не стадает при существенном выигрыше в скорости. Однако гораздо сложнее доказать это строго математически, а потому я не берусь настаивать на таком решении проблемы.
---
Есть подводные камни. Например: если модификация параметров эксперта влечёт за собой изменение продолжительности расчётов (например увеличение периода индикатора с необходимостью замедляет обработку), то предложенный "турбо"-режим будет приводить к отбрасыванию преимущественно "медленных" решений, которые далеко не всегда являются худшими. Тенденция эта очень слабая (гораздо менее 2%) и я ей склонен просто пренебречь, однако для шибко принципиального юзера она может выглядеть недопустимой.
Отсюда снова вывод - режим обязан быть опциональным и использоваться осознанно с пониманием особенностей.
Предлагаю на обсуждение общественности, если в целом одобрямс - буду отправлять маляву в сервисдеск.