Теория ускорения работы советника при использовании пользовательского индикатора (функция - iCustom)
Компилятор может и многое может, но не это :-)
А это дело можно оптимизировать. Во-первых, сам индикатор должен быть по уму написан (не пересчитывать все бары на каждом тике), во-вторых индикатор должен быть супер тяжёлым, чтобы как-то замедлять работу советника... это если коротко...
А вот интересная статья на тему: "Уменьшаем расход памяти на вспомогательные индикаторы".
Был у меня мультивалютный советник, к-рый принимал показания индикаторов для 28 инструментов на 8 тф.
Это 28*8=224 копии индикаторов... я мучался, как оптимизировать процесс. Работа мультивалютника жрала оперативки почти 700 МБ... а решился довольно-таки легко - просто в настройках терминала на вкладке "Графики" для поля "Макс.баров в окне" поставил небольшое значение... насколько помню минимум для этого поля - это 5 тыс. баров...
- 2011.03.18
- Andrew
- www.mql5.com
Проводил замеры, увеличение времени тестирование в 1,2 - 1,3 раза, что есть совершенно несущественно по сравнению с преимуществами даваемыми пользовательскими индикаторами.
Про 5-ть буферов вывод неверный. Если параметры одинаковы то будет загружен только один индикатор.
Integer:
Про 5-ть буферов вывод неверный. Если параметры одинаковы то будет загружен только один индикатор.
Да, согласен.
Будет 5 вызовов функции CopyBuffer() с разными аргументами (номер буфера). А копия индикатора - хэндл- будет одна.
Автор громко назвал топик "Теория ускорения...", а в базовых вещах - ни в зуб ногой.
-Aleks-, есть же масса статей на индикаторную тему!
Да, согласен.
Будет 5 вызовов функции CopyBuffer() с разными аргументами (номер буфера). А копия индикатора - хэндл- будет одна.
Автор громко назвал топик "Теория ускорения...", а в базовых вещах - ни в зуб ногой.
-Aleks-, есть же масса статей на индикаторную тему!
denkir , я говорю о работе советника в процессе оптимизации, там разве количество свечей на графике влияет на объём вычислений? Статью я изучал, про оптимизацию самих индикаторов - знаю, что есть варианты. Однако, в данном случае хотелось бы считать, что индикатор идеален и исследовать метод передачи данных от индикатора к советнику. Мне, как не программисту, трудно проверить оптимальность кода индикатора - максимум что могу прописать в ТЗ - лаг на 1 бар и ограничение истории для расчета.
Проводил замеры, увеличение времени тестирование в 1,2 - 1,3 раза, что есть совершенно несущественно по сравнению с преимуществами даваемыми пользовательскими индикаторами.
Про 5-ть буферов вывод неверный. Если параметры одинаковы то будет загружен только один индикатор.
Замеры чего производили? И, 30% это не так и мало, для меня.
Про 5-ть буферов, если я правильно Вас понял, то при одинаковых входных параметрах индикатора расчет происходит только одного индикатора при многократном вызове последнего советником и получении информации с разных буферов?
Если это так, то объединение пользовательских индикаторов должно давать ускорение работы советника? К примеру в один индикатор тогда можно заложить логику разных индикаторов с независимыми настройками, при вызове любого из них принимается сразу информация со всех буферов и используется в случае запроса информации с другого буфера с теми же параметрами?
VDev:
Пробовал как-то замерять скорость вызова встроенных индюков и их аналогов через iCustom. Встроенные быстрее примерно на 20-50%. Скорее всего потому, что написаны на С++, а не на MQL.
Крайне интересная статья "Усреднение ценовых рядов без дополнительных буферов для промежуточных расчетов" от GODZILLA.
Писана ещё в 2010.
Там есть раздел 3. Сравнение полученного индикатора с использованием классов с его аналогами с вызовами технических и пользовательских индикаторов в коде
- 2010.10.25
- Nikolay Kositsin
- www.mql5.com
Да, согласен.
Будет 5 вызовов функции CopyBuffer() с разными аргументами (номер буфера). А копия индикатора - хэндл- будет одна.
Автор громко назвал топик "Теория ускорения...", а в базовых вещах - ни в зуб ногой.
-Aleks-, есть же масса статей на индикаторную тему!
А можете просто опровергнуть мою гипотезу(на четверке, желательно), подтвердив слова цифрами?
Тема о моей теории - название нормальное :)
denkir , я говорю о работе советника в процессе оптимизации, там разве количество свечей на графике влияет на объём вычислений?
-Aleks-, про Тестер нужно спрашивать у разрабов...
Но, как мне кажется, при обсуждении есть проблема в терминах. Вам что нужно, сократить скорость расчётов или сэкономить оперативку для работы с индикатором?
-Aleks-, про Тестер нужно спрашивать у разрабов...
Но как мне кажется, при обсуждении есть проблема в терминах. Вам что нужно, сократить скорость расчётов или сэкономить оперативку для работы с индикатором?
Мне кажется, что мой метод решит две этих задачи. Возможно я ошибаюсь.
При оптимизации важна скорость, но после забивки ОЗУ, опять же по моим наблюдениям, снижается скорость обработки одного прохода.
Кто-то может сравнить скорость работы такого подхода, есть ли в нём рациональное зерно?
Такой подход уменьшит потребление индикатором памяти (примерно кратно разнице в кол-ве буферов до и после), но увеличит нагрузку на процессор (и "сборку" и "разложение" надо постоянно делать).
А если индикатор 5-тибуферный, то первый же вызов iCustom рассчитает все буферы, последующие вызовы и запросы других буферов будут только читать готовую информацию (вплоть до появления новых данных для расчета).
Если у вас реально тяжелый индикатор, придумайте свою систему кэша, чтоб при первом прогоне данные рассчитывались и записывались в файл, а при псоледующих - только читались. Я так делал, получается сильно быстрее.
Но в 95% случаев в этом всем нет необходимости, тестер и так достаточно быстрый, а в 5-ке можно еще и облако подключить.
Удачи!
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Начну с того, что я не являюсь программистом, и могу ошибаться, но хотелось бы услышать обоснованное на вычислениях мнение профессионалов о предложенной ниже идеи.
Использование пользовательских индикаторов - актуальная задача при разработке советника в несколько этапов. Особенно это актуально, когда программисты сменяют друг друга и тогда часть логики советника лучше зашить в индикатор - обкатать логику (проверить вычисления и их актуальность), и дальше работать над новой частью идеи. В итоге получается не очень сложный советник, который фактически запрашивает информацию у индикатора и принимает решение путем сравнения ожидаемых и фактических данных.
Но, в данном подходе есть существенный недостаток - скорость работы такого эксперта. Дело в том, что чем чаще запрашиваются данные от пользовательских индикатор, тем медленней расчет и больше требуется ресурсов (памяти) для оптимизации.
Пока я работаю в 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 цифры, которые можно в дальнейшем использовать для работы советника.
Кто-то может сравнить скорость работы такого подхода, есть ли в нём рациональное зерно?