Посмотрим с другой стороны. Если индикаторы работают в своих потоках, это будет означать, что советник будет регулярно использовать устаревшие данные индикаторов. Часть индикаторов по новому тику. что часть по старому. Оно надо? Нормально ли это? Кто в лес, кто по дрова.
Занимаюсь миграцией с системы С#+БД на советник МТ5. Хочу кое что посмотреть- проверить, попробовать. Для начала выбросил БД, потом потоки, .... потом все остальное. Переписал индикаторы (еще не все, но основные), сделал советника - уже даже тестируется Есть еще нельзя, но уже мажется. :)
Вот что напрягает, так это - советник исполняется в потоке графика.
Имеем на систему 30 индикаторов (пугаться не надо, это всего лишь типа матрицы), по времени исполнения ~5-15 ЕМА каждый + надо обработку каждого тика + открытие-закрытие позиции, если потребуется.
Система изначально скальперская, имеется в виду открытие-закрытие сделки. В С# было наплевать, т.к. там были потоки и все считалось независимо, и данные читались, по возможности, независимо от того закончились ли вычисления в других потоках.
А вот здесь, мне сдается, что я сильно не успеваю, и если каждый цикл буду пропускать по неск тиков, то и миграция теряет всякий смысл. Можно распараллелить через DLL, но хочется избежать внешних сношений. DLL конечно, оно неплохо, но события из нее в терминал никак не передашь.
Ох уж этот MQL :(
Это не поможет ускорить расчеты? https://www.mql5.com/ru/docs/opencl
Кстати, у Интела есть свободная библиотеке OpenCL, которая распараллеливает и на обычном проце. Пробовал давно уже, работал.
- www.mql5.com
Это не поможет ускорить расчеты? https://www.mql5.com/ru/docs/opencl
Кстати, у Интела есть свободная библиотеке OpenCL, которая распараллеливает и на обычном проце. Пробовал давно уже, работал.
Спасибо. Думаю не вариант.
Думаю, м.б. DLL все таки, но тогда нужно БД подтягивать и импорт данных из МТ5. А это возврат к прежней системе С# + БД. Только все переписывать с нуля под МТ5 + DLL-ки.
Т.е. В МТ5 ничего и не остается, кроме обращений к DLL.
ИМХО, что-то не так с МТ5 и MQL, если не получается организовать, в общем, простую, но даже со средним объемом вычислений, систему.
Понятно, что сам дурак. :)
ЗЫ Как не собирай, а все автомат калашникова S# получается. :)
Спасибо. Думаю не вариант.
Думаю, м.б. DLL все таки, но тогда нужно БД подтягивать и импорт данных из МТ5. А это возврат к прежней системе С# + БД. Только все переписывать с нуля под МТ5 + DLL-ки.
Т.е. В МТ5 ничего и не остается, кроме обращений к DLL.
ИМХО, что-то не так с МТ5 и MQL, если не получается организовать, в общем, простую, но даже со средним объемом вычислений, систему.
Понятно, что сам дурак. :)
Я надеюсь, вы не собираететсь вешать 30 индикаторов на график? :)
Если нет, то даже не представляю, что можно написать такого, чтобы в оптимизированном виде вычисления занимали >10-20 мс.
Я надеюсь, вы не собираететсь вешать 30 индикаторов на график? :)
Если нет, то даже не представляю, что можно написать такого, чтобы в оптимизированном виде вычисления занимали >10-20 мс.
Нет, не собираюсь, наверное даже вообще не собираюсь (в смысле визуализации). :) Ну, разве только для отладки. Там еще своя доморощенная БД на буферах, чтобы не пересчитывать, реализованная как индикатор.
Расчет одной точки 5-15 времени ЕМА - эт много? - скажем, вместо 2-х сложений-умножений 5-15. Не весть какие сложные вычисления. Ну и умножить на 30 + еще немного на обработку и принятие решения.
Но я сильно подозреваю (не без оснований), что поезд за это время вполне может уйти.
ЗЫ В качестве примера - состояние 1 точки в пространстве описывается минимально 24 параметра. :)
Нет, не собираюсь, наверное даже вообще не собираюсь. :) Ну, разве только для отладки. Там еще своя доморощенная БД на буферах, чтобы не пересчитывать, реализованная как индикатор.
Расчет одной точки 5-15 времени ЕМА - эт много? - вместо 2-х сложений-умножений 5-10. Не весть какие сложные вычисления. Ну и умножить на 30 + еще немного на обработку и принятие решения.
Но я сильно подозреваю (не без оснований), что поезд за это время вполне может уйти.
ЗЫ Вообще-то 1 точка в пространстве - это минимально 24 параметра. :)
Вот что напрягает, так это - советник исполняется в потоке графика.
Каждый советник работает только в своем собственном потоке.
Индикаторы, вызываемые из этого советника, работают в потоке этого же советника и не влияют на чарты или остальных советников.
Каждый советник работает только в своем собственном потоке.
Да, нашел. Спасибо. Выполнение программ
Индикаторы, вызываемые из этого советника, работают в потоке этого же советника и не влияют на чарты или остальных советников.
А это где? Вижу только
Один поток выполнения для всех индикаторов на одном символе. Сколько символов с индикаторами - столько потоков выполнения для них
и
Все индикаторы, рассчитываемые на одном символе, даже если они запущены на разных графиках, работают в одном потоке. Таким образом, все индикаторы на одном символе делят между собой ресурсы одного потока.
1. Можно ли разместить 2-х экспертов в на одном графике. Непринципиально, но интересно.
2. Возможен ли обмен данными между различными экспертами? Или только через глобальные переменные терминала?
зы Интересно. Можно создать глобальные переменные с именами g[0],g[1],g[2] и т.д. Прокатывает. А можно ли к ним обращаться как к массиву, типа GlobalVariableSet(g[i], 0.01), GlobalVariableGet(g[i])? Попробую сам, когда руки дойдут, но м.б. кто знает?
Да, нашел. Спасибо. Выполнение программ
А это где? Вижу только
Один поток выполнения для всех индикаторов на одном символе. Сколько символов с индикаторами - столько потоков выполнения для них
Индикатор, вызываемый из эксперта, является подчиненным этому эксперту и поэтому работает в потоке эксперта.
Индикаторы, прикрепленные к графикам, живут по описанным выше правилам: группируются в потоке каждого символа.
1. Можно ли разместить 2-х экспертов в на одном графике. Непринципиально, но интересно.
2. Возможен ли обмен данными между различными экспертами? Или только через глобальные переменные терминала?
Да, конечно.
Для одиночных данных можно использовать GlobalVariableSet, а для массивных обмен через графические ресурсы(виртуальные битмапы). Например, если надо передавать мегабайты данных, то быстрее будет через разделяемые графические ресурсы. Также можно использовать файлы.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Занимаюсь миграцией с системы С#+БД на советник МТ5. Хочу кое что посмотреть- проверить, попробовать. Для начала выбросил БД, потом потоки, .... потом все остальное. Переписал индикаторы (еще не все, но основные), сделал советника - уже даже тестируется Есть еще нельзя, но уже мажется. :)
Вот что напрягает, так это - советник исполняется в потоке графика.
Имеем на систему 30 индикаторов (пугаться не надо, это всего лишь типа матрицы), по времени исполнения ~5-15 ЕМА каждый + надо обработку каждого тика + открытие-закрытие позиции, если потребуется.
Система изначально скальперская, имеется в виду открытие-закрытие сделки. В С# было наплевать, т.к. там были потоки и все считалось независимо, и данные читались, по возможности, независимо от того закончились ли вычисления в других потоках.
А вот здесь, мне сдается, что я сильно не успеваю, и если каждый цикл буду пропускать по неск тиков, то и миграция теряет всякий смысл. Можно распараллелить через DLL, но хочется избежать внешних сношений. DLL конечно, оно неплохо, но события из нее в терминал никак не передашь.
Ох уж этот MQL :(