Обсуждение статьи "Уменьшаем расход памяти на вспомогательные индикаторы"

 

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

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

Автор: Andrew

 

Подход понятен. Но вот смущает актуальность задачи.

При том что 64-битная система поддерживает огромные объёмы оперативы, актуальность задачи как то меркнет. Да даже 32-бит с его 3Гб вполне тянет такие размеры памяти какие вы экономите. Ведь как ни крути а память при загрузке новых индикаторов растёт линейно, а значит 48Мб больше или меньше для современных компов семечки.

Ладно, предположим что задача актуальна (согласен что есть люди которым это важно). Но задумайтесь, задача экономии памяти напрямую идёт в разрез с задачей быстродействия.

Так что на этот момент тоже нужно обращать внимание.

Насколько мне с моей колокольни видно, MQ борятся за быстродействие и именно тут сконцентрированы все усилия. 

Если же вам нужно сэкономить ресурсы памяти на нерисуемых индикаторах то просто перенесите код индикатора в советник. Тут у вас будет полный контроль над выделяемой памятью. За одно можно будет сэкономить на получении однотипных данных. Многие индикаторы запрашивают одни и те же данные каждый для своей обработки над ними. Получив данные один раз можно будет не обращаться к ним в последующем.

Теперь совместим обе задачи быстродействие и объём памяти. Большинство нерисуемых индикаторов занимается обсчётом последнего бара, на это указывает встроенные механизмы блокировки пересчёта всего массива. Получается что в советнике вообще можно будет выделять (ну например на расчёт машки периодом 153) 154 ячейки памяти при такой экономии памяти быстродействие будет не хуже чем в обычном индикаторе.

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

Документация по MQL5: Основы языка / Переменные
Документация по MQL5: Основы языка / Переменные
  • www.mql5.com
Основы языка / Переменные - Документация по MQL5
 

Согласен, быстродействие это основной приоритет и экономить память нет смыла (если конечно не юзается памяти больше 1Gb, что маловероятно).


 
Urain:

Подход понятен. Но вот смущает актуальность задачи.

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

Да даже 32-бит с его 3Гб вполне тянет такие размеры памяти

Если торговать на большом количестве пар, то не тянет, в том-то и дело.

Терминал, кстати, не может выделить памяти больше 2 Гб (в сумме: оперативная + виртуальная). В моих экспериментах он закрывался на этой отметке.

В 64 бит такой проблемы, конечно, существовать не должно.

Ладно, предположим что задача актуальна (согласен что есть люди которым это важно). Но задумайтесь, задача экономии памяти напрямую идёт в разрез с задачей быстродействия.

Не всегда. В статье, вот, как раз большинство методов не снижают быстродействия.

Если же вам нужно сэкономить ресурсы памяти на нерисуемых индикаторах то просто перенесите код индикатора в советник.

Советник, запрашивающий от индикаторов лишь последний бар, - это уже другой класс программы, нежели рассмотренный в статье. И не всегда возможно/удобно заменить одно на другое.

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

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

 
ds2:

Проблема индикаторов в том что каждый работает в своём потоке и для работы должен в самом потоке хранить все необходимые данные.

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

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



Как написать индикатор в MQL5
Как написать индикатор в MQL5
  • 2010.01.12
  • MetaQuotes Software Corp.
  • www.mql5.com
Что представляет собою индикатор? Это набор вычисленных значений, которые мы хотим отобразить на экране монитора удобным для нас образом. Наборы значений представляются в программах в виде массивов. Таким образом, создание индикатора - это написание алгоритма, который обрабатывает одни массивы (массивы цен) и записывает результаты обработки в другие массивы (значения индикаторов). На примере создания индикатора True Strength Index в статье рассказывается, как писать индикаторы на MQL5