Тестирование нового компилятора MQL5 для x64 платформ - ускорение расчетов от 2 до 10 раз! - страница 20

 
Denis Kirichenko:

Оптимизировать логику. Например поработать с массивами и циклами. Попробовать значения критериев упаковать в массив. А проверки делать в цикле. Может тогда потребность в 74-х тысячах case'ов и отпадёт...

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

 
Alexey Kozitsyn:

1.  Вы там увидите самые "тормознутые" места в коде. Хотя... еще вопрос, влияет ли это на компиляцию...

2. Как хотите: можете через case. Вам же посоветовали разбить на мелкие функции. Разбейте и проверьте. Да, конечно, код еще больше увеличится. А что делать.

А вот я переделал код на функции - в приложении.

Сразу обращает на себя внимание, что прежний код занимал 14428 кб после компиляции, а новый 9447 кб - уже удивляет разница в 5 мегабайт - откуда!?

Дальше по скорости компиляции, прежний вариант 

0 error(s), 0 warning(s), 2109302 msec elapsed

новый вариант

0 error(s), 0 warning(s), 386131 msec elapsed

Новый вариант быстрей в 5,46 раз компилируется!

А вот по скорости работы, прежний вариант:

2019.10.15 14:35:47.593 Core 1  pass 0 returned result 1001000.000000 in 0:00:29.555
2019.10.15 14:35:47.595 Core 3  pass 4 returned result 1001000.000000 in 0:00:29.490
2019.10.15 14:35:47.605 Core 2  pass 2 returned result 1001000.000000 in 0:00:29.540
2019.10.15 14:35:47.641 Core 4  pass 6 returned result 1001000.000000 in 0:00:29.541
2019.10.15 14:36:15.511 Core 2  pass 3 returned result 1001000.000000 in 0:00:27.907
2019.10.15 14:36:15.523 Core 1  pass 1 returned result 1001000.000000 in 0:00:27.932
2019.10.15 14:36:15.535 Core 3  pass 5 returned result 1001000.000000 in 0:00:27.942
2019.10.15 14:36:15.537 Core 4  pass 7 returned result 1001000.000000 in 0:00:27.897
2019.10.15 14:36:15.537 Tester  optimization finished, total passes 8
2019.10.15 14:36:15.547 Statistics      optimization done in 0 minutes 58 seconds
2019.10.15 14:36:15.547 Statistics      shortest pass 0:00:27.897, longest pass 0:00:29.555, average pass 0:00:28.725
2019.10.15 14:36:15.547 Statistics      8000 frames (3.14 Mb total, 412 bytes per frame) received
2019.10.15 14:36:15.547 Statistics      local 8 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)

новый вариант

2019.10.15 14:33:51.458 Core 3  pass 6 returned result 1001000.000000 in 0:01:01.840
2019.10.15 14:33:51.485 Core 2  pass 4 returned result 1001000.000000 in 0:01:01.867
2019.10.15 14:33:51.521 Core 1  pass 2 returned result 1001000.000000 in 0:01:01.903
2019.10.15 14:33:51.524 Core 4  pass 0 returned result 1001000.000000 in 0:01:01.906
2019.10.15 14:34:18.802 Core 3  pass 7 returned result 1001000.000000 in 0:00:27.346
2019.10.15 14:34:18.837 Core 2  pass 5 returned result 1001000.000000 in 0:00:27.354
2019.10.15 14:34:18.892 Core 4  pass 1 returned result 1001000.000000 in 0:00:27.370
2019.10.15 14:34:18.922 Core 1  pass 3 returned result 1001000.000000 in 0:00:27.403
2019.10.15 14:34:18.922 Tester  optimization finished, total passes 8
2019.10.15 14:34:18.932 Statistics      optimization done in 1 minutes 29 seconds
2019.10.15 14:34:18.932 Statistics      shortest pass 0:00:27.346, longest pass 0:01:01.906, average pass 0:00:44.623
2019.10.15 14:34:18.932 Statistics      8000 frames (3.14 Mb total, 412 bytes per frame) received
2019.10.15 14:34:18.932 Statistics      local 8 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)

И тут видно, что первый проход агентов (4 агента) очень медленный - пробовал много раз - результат устойчив, а в логе

2019.10.15 14:38:07.002 Tester  OnTesterInit works too long...

С чем это связано теперь, может  @Renat Fatkhullin или @Slava подскажут, почему такой эффект?

Файлы:
 
Andrey Khatimlianskii:

Файл сожмите зипом. Читайте зип, распаковывайте внутри. Будет быстрее, чем передавать 500 Мб советника (он тоже каждому агенту передается).

А разве потом не происходит повторной распаковки при каждом новом проходе?

Да и будет ли чтение из файла быстрей, чем единоразовый переброс....

 
Aleksey Vyazmikin:

А разве потом не происходит повторной распаковки при каждом новом проходе?

Да и будет ли чтение из файла быстрей, чем единоразовый переброс....

Да, при оптимизации может оказаться медленнее.. Но я бы проверил, все же готово для этого.

 
Andrey Khatimlianskii:

Да, при оптимизации может оказаться медленнее.. Но я бы проверил, все же готово для этого.

Что именно готово - не понял.

 
Aleksey Vyazmikin:

Что именно готово - не понял.

Работа с зип-архивами.

 
Andrey Khatimlianskii:

Работа с зип-архивами.

Да, я видел, но не пробовал как оно на деле работает.

Тут скорей проблема в большей степени для меня это в подготовке данных, т.е. переводе кода в таблицу - надо будет снова произвести обработку исходных данных...

 
К сожалению, оказалось, что компилятор не способен справится с большим кодом - получил ошибку "EX5 write error" - других ошибок нет. Об ограничениях хорошо бы написать в руководстве пользователя!
 
Сделал публичную версию советника, сейчас проверяю - откомпилируется или нет - процесс не быстрый, однако сейчас видно, что 46% кода откомпилировано и при этом уже 36 гигабайт ОЗУ съедено...
 
Aleksey Vyazmikin:
Сделал публичную версию советника, сейчас проверяю - откомпилируется или нет - процесс не быстрый, однако сейчас видно, что 46% кода откомпилировано и при этом уже 36 гигабайт ОЗУ съедено...

Предоставте пожалуйста код мне для исследования.
Я проверю, почему он компилируется так медленно и потребляет столько памяти.

Причина обращения: