MT5 и скорость в боевом исполнении - страница 71
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Предлагаю на этом закончить теоретизирование, которое никогда не будет пересекаться здесь с практикой.
Тогда и вам предлагаю прекратить бессмысленные однопоточные синхронные тесты.
Ожидая получить параллельные результаты.
Нафиг такое. MQL-программы станут сложнее на порядок, если из разных потоков будет read\write доступ к внутренним переменным, например.
Просто MQL6 должен быть похож на Erlang, а не С++ )
Тогда и вам предлагаю прекратить бессмысленные однопоточные синхронные тесты.
Ожидая получить параллельные результаты.
Меня волнуют случающиеся почти на каждом тике лаги большой величины. Это никакого отношения к потокам не имеет. Разработчики разбираются.
Просто MQL6 должен быть похож на Erlang, а не С++ )
тогда лучше Scala
.... но как ни крути, за обёртками вот этих сильных функциональных языков с динамической типизацией... все равно будет находиться машинный С++, Python этому подтверждение, обсуждаемый java с event loop-ами вообще из другой галактики, в которой нужно иметь распределенную многопроцессорную систему, чтобы получить некое расширение и масштабируемость вычислительной системы
В школе.
- Вовочка, как используют куриный пух?
- Не знаю.
- Ну а на чем ты спишь?
- На полу.
- А на что голову кладешь?
- На валенок.
- А на чем родители опят?
- На полу.
- А на что головы кладут?
- На валенки.
- А на чем бабушка спит?
- На печке.
- А на что голову кладет?
- На подушку.
- Ну а в подушке-то, что - пух?
- А в подушке валенок.
тогда лучше Scala
.... но как ни крути, за обёртками вот этих сильных функциональных языков с динамической типизацией... все равно будет находиться машинный С++, Python этому подтверждение, обсуждаемый java с event loop-ами вообще из другой галактики, в которой нужно иметь распределенную многопроцессорную систему, чтобы получить некое расширение и масштабируемость вычислительной системы
В том то и дело, что Python написан на Си, а в Python есть библиотека asyncio, которая основана на модели event loop.
Вот тебе и анекдот с валенком ))
тогда лучше Scala
Главное, чтобы с компиляцией в VHDL и изготовлением своего сервера)
Обсуждение ушло куда-то с в сторону - скорость интеграции с Python конечно важный вопрос, однако есть масса базовых проблемных моментов, влияющих на скорость исполнения советников.
Предлагаю сосредоточиться на той проблеме, что в функции OnTradeTransaction в конечном вызове TRADE_TRANSACTION_HISTORY_ADD поля структур MqlTradeTransaction и MqlTradeResult практически пусты, т.е. не заполняются по аналогии с тем как ордер затем отражатеся в закладке "История" и как они подаются в Справке/Документации. Правка этого недостатка уже даст реальное ускорение в боевом исполнении, так как не нужно будет лишний раз вызывать HistoryOrderSelect для получения исчерпывающих значений об исполненном ордере.
И в целом на уровне всего Mql-комьюнити устранение данной пробелмы приведет к массоволму снижению трудозатрат на создание различных костылей в советниках для обхода недостатков текущей реализации OnTradeTransactio.
Вот вопрос как повлиять на команду разрабтчиков MQ? может быть сделать отдельный пост с голосованием а-ка сбором подписей за устранение этого недостатка данной функции?
Вот вопрос как повлиять на команду разрабтчиков MQ?
Вроде, мой рецепт работает: воспроизводящий проблему лаконичный код.
Обсуждение ушло куда-то с в сторону - скорость интеграции с Python конечно важный вопрос, однако есть масса базовых проблемных моментов, влияющих на скорость исполнения советников.
Предлагаю сосредоточиться на той проблеме, что в функции OnTradeTransaction в конечном вызове TRADE_TRANSACTION_HISTORY_ADD поля структур MqlTradeTransaction и MqlTradeResult практически пусты, т.е. не заполняются по аналогии с тем как ордер затем отражатеся в закладке "История" и как они подаются в Справке/Документации. Правка этого недостатка уже даст реальное ускорение в боевом исполнении, так как не нужно будет лишний раз вызывать HistoryOrderSelect для получения исчерпывающих значений об исполненном ордере.
И в целом на уровне всего Mql-комьюнити устранение данной пробелмы приведет к массоволму снижению трудозатрат на создание различных костылей в советниках для обхода недостатков текущей реализации OnTradeTransactio.
Вот вопрос как повлиять на команду разрабтчиков MQ? может быть сделать отдельный пост с голосованием а-ка сбором подписей за устранение этого недостатка данной функции?
Python как раз хорошо показывает событийную модель. А анекдот Игоря как раз в тему.
И если разработчик уловил смысл примера, то понял куда нужно копать.
Любое ожидание своевременного получения результата, рано или поздно упирается в синхронную модель выполнения.
В mql это наступило. Возможности языка очень богаты, но искусственно ограничены синхронным выполнением.
Roman:
Не понимание примера с Python, говорит о не понимании обсуждения асинхронности в целом.
самый непонимающий здесь это ты. не зафлуживай ветку