Скачать MetaTrader 5

Теория ускорения работы советника при использовании пользовательского индикатора (функция - iCustom)

Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий
Aleksey Vyazmikin
8827
Aleksey Vyazmikin  

Начну с того, что я не являюсь программистом, и могу ошибаться, но хотелось бы услышать обоснованное на вычислениях мнение профессионалов о предложенной ниже идеи.

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

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

Пока я работаю в MT4, но принцип, как я понимаю, этой проблемы одинаков.

А проблема заключается не в скорости расчетов самого индикатора iCustom, а именно в его связке с советником.

Допустим, индикатор использует 5 графических буферов и для работы советника требуется информация с этих буферов, тогда в коде советника необходимо использовать 5 функций iCustom, и фактически вместо одного индикатора наносить на график 5 индикаторов, что требует в 5 раз больше ресурсов. Быть может я не прав и компилятор анализирует это обстоятельство - делая расчет по одному индикатору и дает сразу всем функциям данные по востребованным буферам!? Тогда дальше мои измышления пусты.

Но, если это не так, то почему бы не объединить информацию от индикатора в один паток?

Предлагаю провести на эту тему эксперимент с замеров производительности советника.

Для этого потребуется взять пользовательский индикатор с буфером более 1 и добавить дополнительный буфер.

Алгоритм логический (без математического):

1. Преобразуем в индикаторе значение буферов в целые числа, в зависимости от числовых знаков на число, всего 3 буфера, было: 1,21101; 1,13; 5, стало: 121101;113;5

2. Считаем, сколько нужно вместить цифр после первого числа - в нашем случае 4, потом в последующее число следующее - 1, эти значения являются степенью множителя:

1,21101*10^4=1211010000

1.13*10^1=113

5*10^0=5 (делам проверку на 0)

3. Суммируем числа и получаем 1211011135

4. Записываем значение в 4 буфер

5. Запрашиваем в советнике 4 буфер индикатора и производим разложение значения на составляющие в обратном порядке - получаем 3 цифры, которые можно в дальнейшем использовать для работы советника.

Кто-то может сравнить скорость работы такого подхода, есть ли в нём рациональное зерно?

Dennis Kirichenko
11539
Dennis Kirichenko  
...Допустим, индикатор использует 5 графических буферов и для работы советника требуется информация с этих буферов, тогда в коде советника необходимо использовать 5 функций iCustom, и фактически вместо одного индикатора наносить на график 5 индикаторов, что требует в 5 раз больше ресурсов. Быть может я не прав и компилятор анализирует это обстоятельство - делая расчет по одному индикатору и дает сразу всем функциям данные по востребованным буферам!? Тогда дальше мои измышления пусты...

Компилятор может и многое может, но не это :-)

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

А это дело можно оптимизировать. Во-первых, сам индикатор должен быть по уму написан (не пересчитывать все бары на каждом тике), во-вторых индикатор должен быть супер тяжёлым, чтобы как-то замедлять работу советника... это если коротко...

А вот интересная статья на тему: "Уменьшаем расход памяти на вспомогательные индикаторы".

Был у меня мультивалютный советник, к-рый принимал показания индикаторов для 28 инструментов на 8 тф.

Это 28*8=224 копии индикаторов... я мучался, как оптимизировать процесс. Работа мультивалютника жрала оперативки почти 700 МБ... а решился довольно-таки легко - просто в настройках терминала на вкладке "Графики" для поля "Макс.баров в окне" поставил небольшое значение... насколько помню минимум для этого поля - это 5 тыс. баров...

Уменьшаем расход памяти на вспомогательные индикаторы
Уменьшаем расход памяти на вспомогательные индикаторы
  • 2011.03.18
  • Andrew
  • www.mql5.com
Если индикатор для своих расчетов задействует значения множества других индикаторов, то такая система расходует много памяти. В статье рассмотрены несколько способов снижения расхода памяти при использовании вспомогательных индикаторов. Сэкономленная память позволит вам увеличить число одновременно используемых в терминале валютных пар, индикаторов и стратегий, что повысит надежность вашего торгового портфеля. Вот так простая забота о технических ресурсах вашего компьютера способна превратиться в материальные ресурсы на вашем депозите.
Dmitry Fedoseev
46174
Dmitry Fedoseev  

Проводил замеры, увеличение времени тестирование в 1,2 - 1,3 раза, что есть совершенно несущественно по сравнению с преимуществами даваемыми пользовательскими индикаторами

Про 5-ть буферов вывод неверный. Если параметры одинаковы то будет загружен только один индикатор. 

Dennis Kirichenko
11539
Dennis Kirichenko  

Integer:

Про 5-ть буферов вывод неверный. Если параметры одинаковы то будет загружен только один индикатор. 

Да, согласен.

Будет 5 вызовов функции CopyBuffer() с разными аргументами (номер буфера). А копия индикатора - хэндл- будет одна.

Автор громко назвал топик "Теория ускорения...", а в базовых вещах  - ни в зуб ногой.

-Aleks-, есть же масса статей на индикаторную тему!


Alexey Volchanskiy
21032
Alexey Volchanskiy  
denkir:

Да, согласен.

Будет 5 вызовов функции CopyBuffer() с разными аргументами (номер буфера). А копия индикатора - хэндл- будет одна.

Автор громко назвал топик "Теория ускорения...", а в базовых вещах  - ни в зуб ногой.

-Aleks-, есть же масса статей на индикаторную тему!


Пробовал как-то замерять скорость вызова встроенных индюков и их аналогов через iCustom. Встроенные быстрее примерно на 20-50%. Скорее всего потому, что написаны на С++, а не на MQL.
Aleksey Vyazmikin
8827
Aleksey Vyazmikin  

denkir , я говорю о работе советника в процессе оптимизации, там разве количество свечей на графике влияет на объём вычислений? Статью я изучал, про оптимизацию самих индикаторов - знаю, что есть варианты. Однако, в данном случае хотелось бы считать, что индикатор идеален и исследовать метод передачи данных от индикатора к советнику. Мне, как не программисту, трудно проверить оптимальность кода индикатора - максимум что могу прописать в ТЗ - лаг на 1 бар и ограничение истории для расчета.

 

Integer:

Проводил замеры, увеличение времени тестирование в 1,2 - 1,3 раза, что есть совершенно несущественно по сравнению с преимуществами даваемыми пользовательскими индикаторами

Про 5-ть буферов вывод неверный. Если параметры одинаковы то будет загружен только один индикатор. 

Замеры чего производили? И, 30% это не так и мало, для меня.

Про 5-ть буферов, если я правильно Вас понял, то при одинаковых входных параметрах индикатора расчет происходит только одного индикатора при многократном вызове последнего советником и получении информации с разных буферов?

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

 

VDev:
Пробовал как-то замерять скорость вызова встроенных индюков и их аналогов через iCustom. Встроенные быстрее примерно на 20-50%. Скорее всего потому, что написаны на С++, а не на MQL.  

Это факт.
Dennis Kirichenko
11539
Dennis Kirichenko  

Крайне интересная статья "Усреднение ценовых рядов без дополнительных буферов для промежуточных расчетов" от GODZILLA.

Писана ещё в 2010.

Там есть раздел 3. Сравнение полученного индикатора с использованием классов с его аналогами с вызовами технических и пользовательских индикаторов в коде

Усреднение ценовых рядов без дополнительных буферов для промежуточных расчетов
Усреднение ценовых рядов без дополнительных буферов для промежуточных расчетов
  • 2010.10.25
  • Nikolay Kositsin
  • www.mql5.com
Статья о традиционных и не совсем традиционных алгоритмах усреднения, упакованных в максимально простые и достаточно однотипные классы. Они задумывались для универсального использования в практических разработках индикаторов. Надеюсь, что предложенные классы в определенных ситуациях могут оказаться достаточно актуальной альтернативой громоздким, в некотором смысле, вызовам пользовательских и технических индикаторов.
Aleksey Vyazmikin
8827
Aleksey Vyazmikin  
denkir:

Да, согласен.

Будет 5 вызовов функции CopyBuffer() с разными аргументами (номер буфера). А копия индикатора - хэндл- будет одна.

Автор громко назвал топик "Теория ускорения...", а в базовых вещах  - ни в зуб ногой.

-Aleks-, есть же масса статей на индикаторную тему!


А можете просто опровергнуть мою гипотезу(на четверке, желательно), подтвердив слова цифрами?

Тема о моей теории - название нормальное :) 

Dennis Kirichenko
11539
Dennis Kirichenko  
-Aleks-:

denkir , я говорю о работе советника в процессе оптимизации, там разве количество свечей на графике влияет на объём вычислений? 

-Aleks-, про Тестер нужно спрашивать у разрабов...

Но, как мне кажется, при обсуждении есть проблема в терминах. Вам что нужно, сократить скорость расчётов или сэкономить оперативку для работы с индикатором?



Aleksey Vyazmikin
8827
Aleksey Vyazmikin  
denkir:

-Aleks-, про Тестер нужно спрашивать у разрабов...

Но как мне кажется, при обсуждении есть проблема в терминах. Вам что нужно, сократить скорость расчётов или сэкономить оперативку для работы с индикатором?

Мне кажется, что мой метод решит две этих задачи. Возможно я ошибаюсь.

При оптимизации важна скорость, но после забивки ОЗУ, опять же по моим наблюдениям, снижается скорость обработки одного прохода. 

Andrey Khatimlianskii
57828
Andrey Khatimlianskii  
-Aleks-:

Кто-то может сравнить скорость работы такого подхода, есть ли в нём рациональное зерно?

Такой подход уменьшит потребление индикатором памяти (примерно кратно разнице в кол-ве буферов до и после), но увеличит нагрузку на процессор (и "сборку" и "разложение" надо постоянно делать).

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

 

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

Но в 95% случаев в этом всем нет необходимости, тестер и так достаточно быстрый, а в 5-ке можно еще и облако подключить.

Удачи! 

12345678...10
Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий