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