Новая версия платформы MetaTrader 5 build 5120: улучшения и исправления - страница 32

Новый комментарий
 
Forester #:

Увеличение числа блоков памяти роста производительности не дает. Немного странно, что не согласуется с тестом через RAM диск, но таков результат теста. Так что код можно упростить, удалив строки с выбором блока.

Я очень плохо понимаю работу с памятью. Писал методом тыка. Почти ничего не понимаю в этом.


Есть и ограничение на 4 гига и проблема, что выделяемый кусок памяти под котировки может оказаться в своп-файле (у меня он специально отключен, но это редкость).

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


Но она все же продемонстрировала, что можно получить бесплатное кратное ускорение оптимизации, да еще при этом и увеличить размер тестируемой истории.


Надо обходить ограничение на 4 гига для тиковой истории, т.к. этого будет не хватать (в месяц примерно 100 МБ тиков).

Ну и переделать загрузку тиков в память. Сейчас тики помещаются в массив MqlTick[] и затем копируются в общую память. А это в моменте двойной расход RAM.

 
Forester #:

После обеда попробую взять меньше истории для 36 блоков - это около 1 месяца будет.
Но если нужны тесты за несколько лет, то  видимо надо через RAM диск работать (.

Вряд ли на исследование производительности влияет размер блока. Поэтому 100 Мб на блок должны показать объективную картину.

 
Forester #:

Ускорение оптимизации по сравнению с режимом по всем тикам = 39.1/3.2=12.2 раз и по общему времени оптимизации = 103/13=7.9 раз

Ускорение крутое получилось, да еще и при кратно меньшем расходе памяти. Но почему выделенные числа так отличаются - не знаю.


Надо брать какую-нибудь моновалютную ТС и проводить уже несинтетические замеры. Это уже надо подключать через Virtual.

 

Сделал кусок истории на 100мб (25 дней июня)
На реальных тиках:

IsMathMode() = false

Memory1 - Memory2 = 101 MB (see Line 232 in source)
Agents = 36
Passes = 1001
AmountTicks = 1757615 (100 MB)

Performance = 3.1 Ticks (millions)/sec.
TotalTime = 00:00:18.093

[TesterInputs]
inBlockSize=8
inBlocks=1
inDataTotal=40441527
inRange=945||0||1||1000||Y

В мат. режиме:

1 блок
 2  3 4
9
18
36
Performance = 39.4 Ticks (millions)/sec.
TotalTime = 00:00:03.585
 Performance = 47.8 Ticks (millions)/sec.
TotalTime = 00:00:03.426
 Performance = 35.2 Ticks (millions)/sec.
TotalTime = 00:00:03.684
 		 Performance = 43.7 Ticks (millions)/sec.
TotalTime = 00:00:03.533
 Performance = 24.2 Ticks (millions)/sec.
TotalTime = 00:00:04.194
 Performance = 14.5 Ticks (millions)/sec.
TotalTime = 00:00:06.452
 Performance = 8.5 Ticks (millions)/sec.
TotalTime = 00:00:09.849


2 блока и 4 лучшие по Performance (а на 3 почему-то провал) - перепроверял по 3 перезапуска, все примерно как в таблице.
А общее время при этом не сильно меняется.

А после 4 блоков уже заметно снижение и Performance и скорости оптимизации.

 
fxsaber #:

 Но почему выделенные числа так отличаются - не знаю.

На какие то другие процессы - например на чтение тикового массива с RAM и сохранение нескольких его копий в память.

 
Forester #:

На какие то другие процессы - например на чтение тикового массива с RAM и сохранение нескольких его копий в память.

Замер начинается после этого.

int OnTesterInit()
{
  MqlTick Ticks[];

  Memory1 = TerminalInfoInteger(TERMINAL_MEMORY_AVAILABLE);

  return(IsMathMode() && !((FileLoad("RAMDrive\\Ticks.bin", Ticks, FILE_COMMON) > 0) &&
                           // https://www.mql5.com/ru/forum/488793/page26#comment_57301802
                           HandleMemory.Save(Ticks, 1) && // Количество блоков прописывать руками в коде.
                           ParameterSetRange("inDataTotal", false, ArraySize(Ticks), 0, 0, 0)) &&
                           (bool)(StartTime2 = GetMicrosecondCount()));
}
 
Forester #:

2 блока и 4 лучшие по Performance (а на 3 почему-то провал) - перепроверял по 3 перезапуска, все примерно как в таблице.

На скорость влияет еще inBlockSize. Возможно, при большом количестве блоков оптимальнее брать порции больше, чем по восемь тиков.
 
fxsaber #:

Думаю для больших блоков памяти > 4Гб можно их делить на куски по 2 Гб например и при запросе - выбирать нужный.

Вот только задачка про своп -файл может быть сложной.
 
Forester #:

2 блока и 4 лучшие по Performance (а на 3 почему-то провал) - перепроверял по 3 перезапуска, все примерно как в таблице.

Интересно, что у MQ не меняется производительность в режиме по тикам, когда добавляешь агентов (соответственно, и количество их блоков памяти). Но на то MQ и профи, что так смогли написать.

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


Однако, почему фактически советник-пустышка в режиме по тикам проигрывает кратно эмуляции этого режима в мат. режиме, надо MQ разбираться. Ну и нужны несинтетические тесты, конечно. Хотя оптимизация пустышки на несколько секунд все равно вызывает вопросы.

 
Если главная задача - экономия памяти при тестах на данных за несколько лет - то можно и через RAM диск работать, я себе 36 Гб выделял.
1...252627282930313233343536373839...53
Новый комментарий