Обсуждение статьи "MQL5 Cloud Network ускоряет расчеты"

 

Опубликована статья MQL5 Cloud Network ускоряет расчеты:

Сколько ядер на вашем домашнем компьютере? И сколько компьютеров вы можете задействовать для оптимизации торговой стратегии? Мы покажем как с помощью MQL5 Cloud Network ускорить расчеты и получить для этого вычислительные мощности по всему миру одним щелчком мыши. Выражение "Время - деньги" становится актуальнее с каждым годом, и не всегда мы можем позволить себе ждать окончания важных расчетов в течение десятков часов или даже дней.

Запуск расчетов в MQL5 Cloud Network


Автор: MetaQuotes

 

А как же генетика? Там "в 100 раз" недостижимо. Хорошо, если в 20-30 раз будет, а то и меньше

 
notused:

А как же генетика? Там "в 100 раз" недостижимо. Хорошо, если в 20-30 раз будет, а то и меньше


https://www.mql5.com/ru/forum/4927/page114     

stringo 2012.02.02 15:50


При расчёте генетического алгоритма в облако отдаётся всё очередное поколение (от 64 до 256 расчётных заданий)

При полном переборе каждому облачному серверу отдаётся по пачке из 512 заданий. Затем при выполнении некоторого количества заданий доливается удвоенное количество (то есть, облачный сервер отчитался о выполнении 5 заданий, ему тут же добавляют 10 заданий)

так что ускорение при ГА не в 20-30, а как минимум в 64 раза, как максимум в 256.

 
Urain:
так что ускорение при ГА не в 20-30, а как минимум в 64 раза, как максимум в 256.
ГА не может быть быстрее перебора аналогичного кол-ва параметров. Узкое место ГА - ожидание самого медленного агента. А оно (в среднем) происходит от 10240 / 256 до 10240 / 64 раз (от 40 до 160 раз, исходя из данных stringo). И скорость определяется именно самым медленным агентом. К тому же, в статье у Rosh было 4 собственных локальных агента -> предел ускорения для ГА может быть 256 / 4 = 64 раза (это чтобы говорить об сравнимых величинах), а в жизни гораздо меньше.
 
notused:
ГА не может быть быстрее перебора аналогичного кол-ва параметров. Узкое место ГА - ожидание самого медленного агента. А оно (в среднем) происходит от 10240 / 256 до 10240 / 64 раз (от 40 до 160 раз, исходя из данных stringo). И скорость определяется именно самым медленным агентом. К тому же, в статье у Rosh было 4 собственных локальных агента -> предел ускорения для ГА может быть 256 / 4 = 64 раза (это чтобы говорить об сравнимых величина), а в жизни гораздо меньше.

Как многие заметили, клауд серверы определяют медленных агентов автоматически и перераздают "заторможенные" проходы другим агентам (как в полном переборе, так и в генетике).

Кроме того, в генетике принимаются агенты с PR>100, что серьезно снижает последствия использования медленных агентов.

 
Проделаю тоже что и Rosh, только задам побольше границы параметров, чтобы генетика была. Как закончится всё - отпишусь.
 

Итак, условия тестирования - 4 ядра Intel Core i5-2500 @ 3.3 GHz, 4Гб ОЗУ, Windows XP 64 bit, terminal x64 bild 581 (PR = 160-180). Во время тестирования был запущен браузер и смотрел киношку. Использовались теже условия что и в статье (советник Moving Avarege, H1, по OHLC на 1 м. + генетика). Настройки:Настройки

Тест на локальных ядрах:

 Локальные ядра

Тест на Cloud:

Cloud 

Не раздумывая, видим, что Cloud посчитал  в 8,7 раз быстрее. Всего-то. Но на самом деле, сеть ещё медленнее, поскольку использовался кеш вычислений.

Итак, локальные ядра выполнили 8704 - 3666 =  5038 проходов за 30 мин. 2 сек = 1802 секунды -> на один проход в среднем тратится 0,3577 секунды.

Cloud выполнили 8704 - 4455 = 4249 проходов за 3 мин. 28 сек = 208 секунды -> время ожидания одного прохода от Cloud в среднем составляет 0,049 секунды.

Итого, Cloud ускорил вычисления в 0,3577 / 0,049 = 7,3 раза (!). 

Мои первоначальные предположения, что показатель возможно дотянет до 20 раз, оказались несколько оптимистичными. А о сотнях и говорить не приходится.

 Да, я использовал мощные ядра, т. е., схитрил немного. Но, факт остаётся фактом - даже те 4249 проходов при генетике сеть сделала за 208 секунд и 14040 проходов при полном переборе за 164 секунды (время ожидания одного прохода -  0,0117 секунды). Итого, генетическое тестирование одного прохода на Cloud в среднем медленнее перебора (на примере рассматриваемого советника) в 0,049 / 0,0177 = 2.8 раз.

 

Я не критикую сеть - безусловно, Cloud Network - лучшее, что было сделано за всё время существования софта для торговли. И очень нужная вещь (хотя мало пользуются, но это придёт со временем).

 Мне хотелось бы больше корректности в рекламных слоганах. Ладно, проехали 

 

Если делать тесты с временем одного прохода меньше секунды, то надо обязательно учитывать network latency (сетевую задержку), который зачастую бывает больше или равен времени "скорострельной" задачи. Мы много усилий приложили к избавлению от системных оверхедов на сетевых задержках путем пакетирования задач. И это у нас получилось, хотя полностью эту проблему нельзя победить.

Ваш пример полностью показывает, что Вы соревновались в краткосрочно борьбе со временем прохода заведомо меньше сетевой задержки. Чтобы реально оценить мощность клауда, нужно отойти от задач со временем исполнения меньше секунды и перейти к более затратным.

Я запустил генетику с аналогичной задачей, но у которой время прохода больше 10 секунд на процессоре i7. В течение часа опубликую результаты по завершению.


 

За 3 мин. 28 сек. использования сети, у меня было списано толи 2, толи 3 цента (в терминале 3, на сайте - 2, и 3 заморожено). Пусть будет 3 или даже для простоты, использование сети для генетики стоит 1 цент за одну минуту. Итого, час - 60 центов, 24 часа = $14,4. Как по мне - это очень дорого. Цены нужно скидывать минимум в три раза, чтобы это стало привлекательным для потребителя (тестируют советников многие, но не все могут/хотят выложить около $15 в день за Cloud, а если бы это было $5 или меньше - желающих бы стало больше).

 Также, для себя я уже прикинул, как предварительно оценить стоимость оптимизации любого советника (в среднем, конечно). Алгоритм для генетики (аналогично и для перебора):

1) Запустить на локальных ядрах (+ можно ещё своих удалённых агентов подключить) генетику Moving Avarage; по окончании высчитать время ожидания одного прохода -> T1

2) Высчитать T1 / 0.049 = T2 - во сколько раз ускоряется оптимизация при генетике в Cloud.

3) Запустить оптимизацию на локальных ядрах (+ можно ещё своих удалённых агентов подключить; должна быть конфигурация как в п. 1) нужного советника и подождать, например, 100 проходов. Высчитать время одного прохода (через лог - найти первую и последние записи) -> T3

4) 10240 * T3 / T2  = T4 -> оценочное время тестирования в Cloud.

5) T4 / 60 = стоимость тестирования в центах.

(ещё можно учесть свои ядра, для этого используем T2' = T2 + 1).

 Это всё оценка на основе оптимизации Moving Avarage. Может, через месяц-другой, в сети появится больше мощных ядер и числа поменяются, а также стоимость.

Думаю, ход моей мысли понятен 

 
Renat:

Ваш пример полностью показывает, что Вы соревновались в краткосрочно борьбе со временем прохода заведомо меньше сетевой задержки

Да, я подозревал, но не учитывал этот момент. Подождём Ваших результатов.

А мой предыдущий пост, п. 2 придётся поправить после Ваших тестов.