Обсуждение статьи "Сравнение MQL5 и QLUA - почему торговые операции в MQL5 до 28 раз быстрее?" - страница 3
![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Одновременно, это когда у вас разница в замерах плавает как 10%.
А вот когда по результатам десятков тестов у вас разница стабильно в 4-5 раз, то обсуждать уже нечего.
У меня разница (не стабильно) на MT5 доходила до двух раз. Поэтому решил, что если замерять производительность, то надо смотреть максимальную частоту (минимальное время между соседними пакетами), с которой приходят пакеты. Написал соответствующий советник
И получил результат
И если ~10ms между соседними BookEvent-событиями - правдоподобно. То 0.035ms - нет. Выходит, что BookEvent-событие создается по тому же принципу, что и Tick-событие:
Поэтому данная реализация измерения не подходит для Tick/Calculate/BookEvent-событий. И как мониторить приход нового котировочного сетевого пакета в MQL5 - пока не ясно.
Любой тест должен содержать защиту от cold старта.
Поэтому пропуск N тиков - это показатель, что мы знаем и учитываем это обстоятельство. Просто чтобы избежать заведомо ожидаемой претензии "почему вы не компенсировали влияние cold старта".
Видео про старт сессии трех терминалов было подготовлено 25 августа 2016 для другой претензии трейдера, который утверждал, что МТ5 тормозит на старте сессии. Как в последствии оказалось, этот трейдер вообще не использовал МТ5, а транслировал домыслы с форума. Также выяснилось, что некоторые трейдеры не были в курсе, что для биржевых инструментов графики строятся не по Bid, а по проторгованным Last ценам. Изменение бидов с непоказом их на чартах они воспринимали как "тормоза МТ5".
Конечно, никаких тормозов нет.
У меня разница (не стабильно) на MT5 доходила до двух раз. Поэтому решил, что если замерять производительность, то надо смотреть максимальную частоту (минимальное время между соседними пакетами), с которой приходят пакеты. Написал соответствующий советник
И получил результат
И если ~10ms между соседними BookEvent-событиями - правдоподобно. То 0.035ms - нет. Выходит, что BookEvent-событие создается по тому же принципу, что и Tick-событие:
Правдоподобно.
Данные приходят транзакционно и то, что вы увидели две последовательные транзакции с коротким таймингом - это отличное доказательство правильности нашего процессинга и производительности как самого терминала, так и подсистемы MQL5.
Еще как подходит.
Посмотрите на наш код - он специально замеряет не единичные короткие данные, а тупо собирает тики за 30 секунд. Это нивелирует любые флуктуации и любые погрешности.
В указанном видео за 30 сек MQL5 получил 1 278 тиков, а QLUA всего 254 тика. Это жесточайший облом для алготрейдинга в QLUA.
Правдоподобно.
Данные приходят транзакционно и то, что вы увидели две последовательные транзакции с коротким таймингом - это отличное доказательство правильности нашего процессинга и производительности как самого терминала, так и подсистемы MQL5.
Но пришли они пачкой в сетевом пакете. Хочу же замерить скорость шлюза.
Еще как подходит.
Посмотрите на наш код - он специально замеряет не единичные короткие данные, а тупо собирает тики за 30 секунд. Это нивелирует любые флуктуации и любые погрешности.
В указанном видео за 30 сек MQL5 получил 1 278 тиков, а QLUA всего 254 тика. Это жесточайший облом для алготрейдинга в QLUA.
Но пришли они пачкой в сетевом пакете. Хочу же замерить скорость шлюза.
Не важно.
Просто тики пришли друг за другом, а МТ5 терминал умудрился их красиво и без тормозов отдать вам.
Вы не поняли меня. QLUA-тормоз никак не волнует - с ним все ясно (и к статье вопросов нет). Хочется получить performance-характеристики самого MT5. И как раз MaxFrequency-способ, как реализовал, не подошел. Т.к. в MT5 есть особенность с созданием Tick/Calculate/BookEvent-событий. Запустите советник у себя - увидите воочию очень быстро.
Принцип "каждый тик - это транзакция, посылаемая независимо" означает, что идеологически все построено правильно. Да и как может быть неправильно, если мы с нуля построили 5 платформ и прошлись по всем граблям не один раз.
Вы получили очень высокую производительность. То, что вы начали придумывать частоту - явные глупости. Данные у нас приходят, когда они появляются. Поэтому говорить о "стабильности/нестабильности частоты" не имеет логического смысла. Вы же не стабильность кварцевого генератора тестируете, а пытаетесь застабилизировать рандомный процесс появления цен в стакане.
Это как раз Квик исходно у себя все процессы построил на контроле частоты снапшотов. С закономерным результатом.
Не важно.
Просто тики пришли друг за другом, а МТ5 терминал умудрился их красиво и без тормозов отдать вам.
Принцип "каждый тик - это транзакция, посылаемая независимо" означает, что идеологически все построено правильно. Да и как может быть неправильно, если мы с нуля построили 5 платформ и прошлись по всем граблям не один раз.
Вы получили очень высокую производительность. То, что вы начали придумывать частоту - явные глупости. Данные у нас приходят, когда они появляются. Поэтому говорить о "стабильности/нестабильности частоты" не имеет логического смысла. Вы же не стабильность кварцевого генератора тестируете, а пытаетесь застабилизировать рандомный процесс появления цен в стакане.
Принцип частоты могу легко объяснить. Стакан формируется самой биржей с непостоянной скоростью, т.к. зависит от действий участников рынка.
Хотел замерить, какова максимальная частота обновления стакана - сколько максимально стаканов может выдать MT5 в единицу времени. Оказалось, что стаканы приходят в MT5 пакетами. Возможно, что стаканы от биржи даже не теряются, а приходят вообще ВСЕ. И BookEvent-событие создается не для пакета, а для всех стаканов в пакете (от более раннего до самого позднего). Время формирования биржей стакана в MQL5 невозможно получить. Время прихода пакета - аналогично. Поэтому получается, что моя реализация замера соответствующей характеристики производительности MT5 не показывает то, что хочется увидеть.
То, что BookEvent формируется пачками - поддерживаю всеми конечностями. Это максимум инфы и минимум геморроя для советника. Вот только с замером производительностью проблема, что описал.
Принцип частоты могу легко объяснить. Стакан формируется самой биржей с непостоянной скоростью, т.к. зависит от действий участников рынка.
Хотел замерить, какова максимальная частота обновления стакана - сколько максимально стаканов может выдать MT5 в единицу времени. Оказалось, что стаканы приходят в MT5 пакетами. Возможно, что стаканы от биржи даже не теряются, а приходят вообще ВСЕ. И BookEvent-событие создается не для пакета, а для всех стаканов в пакете (от более раннего до самого позднего). Время формирования биржей стакана в MQL5 невозможно получить. Время прихода пакета - аналогично. Поэтому получается, что моя реализация замера соответствующей характеристики производительности MT5 не показывает то, что хочется увидеть.
То, что BookEvent формируется пачками - поддерживаю всеми конечностями. Это максимум инфы и минимум геморроя для советника. Вот только с замером производительностью проблема, что описал.
Еще раз повторю - не имеет смысла так замерять частоту и делать такие выводы.
Не пытайтесь замерить частоту рандомного процесса появления цен в стакане на основе разницы во времени между двумя тиками. Вы заведомо получите дикий разброс цифр от 1 до XXXXX.
Вы поставили неправильный вопрос, неправильно подсчитали и сделали неправильные выводы. Заодно тень на плетень навели заявлениями "МТ5 не показывает что хочется увидеть, нельзя замерить".
Никакой проблемы "замера производительности" нет, так как вы совсем не то и не так замеряли. Сами придумали неправильную характеристику и принципиально неправильно посчитали.
ps: а вот мы в тестах частоту прихода котировок замерили правильно путем сбора котировок за 30 сек и поделив на затраченное время.
Еще раз повторю - не имеет смысла так замерять частоту и делать такие выводы.
Не пытайтесь замерить частоту рандомного процесса появления цен в стакане на основе разницы во времени между двумя тиками. Вы заведомо получите дикий разброс цифр от 1 до XXXXX.
Вы поставили неправильный вопрос, неправильно подсчитали и сделали неправильные выводы. Заодно тень на плетень навели заявлениями "МТ5 не показывает что хочется увидеть, нельзя замерить".
ps: а вот мы в тестах частоту прихода котировок замерили правильно путем сбора котировок за 30 сек и поделив на затраченное время.
Я замеряю МАКСИМАЛЬНУЮ частоту, а не текущую! Очень подробно описал причину таких замеров, результаты и дал исходник. Вам почему-то кажется, что я набрасываю тень на MT5.
Любой старичек форума, кто прочтет это обсуждение, поймет, что я имел в виду. И не увидит ни тени в сторону MT5. Моя реализация оказалась неправильной. Моя, не Ваша! Что Вы обороняетесь там, где даже повода не давал.
Именно моя реализация не дает возможности замерить то, что хочется. В MQL5 такой возможности нет и это нормально. Как нормально и то, что мне хочется сока, но MQL5 такой возможности не дает.
Я только поделился результатом, что если кому-то захочется замерить время между соседними вызовами соответствующих событий и трактовать это, как производительность. То надо четко осознавать, что на самом деле будет показано.
Вы в корне неправы.
Какая еще максимальная частота, когда вы по факту собрались мерять дельту рандомного процесса, у которого два события запросто имеют дельту 0?
Если доставка тиков реализована правильно (а у нас она правильная), то вы заведомо получите в максимуме "частоту" = (время отработки MQL5 вызова с кодом программы) / (погрешность таймера).
Теоретически, если уложиться в точность таймера и получить 0 микросекунд, то частота будет бесконечность. Ну и критическая ошибка деления на ноль (у вас в коде нет контроля деления на ноль).
Вы в корне неправы.
Какая еще максимальная частота, когда вы по факту собрались мерять дельту рандомного процесса, у которого два события запросто имеют дельту 0?
Если доставка тиков реализована правильно (а у нас она правильная), то вы заведомо получите в максимуме "частоту" = (время отработки MQL5 вызова с кодом программы) / (погрешность таймера).
Да, так и получаю. Получилось, что рандомный процесс у меня замеряется, а я хотел процесс доставки сетевых пакетов замерить. Но не вышло.
Теоретически, если уложиться в точность таймера и получить 0 микросекунд, то частота будет бесконечность. Ну и критическая ошибка деления на ноль (у вас в коде нет контроля деления на ноль).