MT5 и скорость в боевом исполнении - страница 61
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Чувствую, что без поддержки форумчан эту MQ-стену не пробить. Код короткий, профи должны быстро въехать. Нет там изъянов. Четко показано, что цены через позиции получаются значительно быстрее, чем из Обзора рынка. Как MQ не видят очевидного - не понимаю.
1. Ваш тест реально учитывает микро долю процента итераций благодаря условию
По сути вы только считаете лишь аномалии, когда процессор перегружен задачами и отложил выполнение данной задачи на дальнюю полку, т.к. более 99% итераций выполняется менее чем 1 микросекунду.
И даже если вы поставите условие >0, то всё равно никакой объективности.
2. Замер времени подобных быстрых операций необходимо выполнять только как время полного цикла, а не одной итерации.
3. Но так как цикл в Вашем примере лимитирован 10 секундами ( Зачем! Для тиков думаю вполне хватит 0.1 сек. Ведь вполне возможно, что за секунду придут 3 тика, и все три тика будут отрабатыватся по 10 секунд, причем параллельно), то и замера времени никакого не требуется. А проще посчитать сколько выполнится итераций за заданное время. Чем больше, тем больше производительность.
Я "слегка" модифицировал Ваш код. Думаю, мой вариант больше отражает реальность.
Расчет производится по очереди, чтобы не смешивать два варианта. Четные тики для SYMBOL_BID, нечетные для GetBid().
Суммы и их вывод добавил на всякий случай, как попытку обмануть компилятор против оптимизации.
Выходной результат накопительный.
мой результат:
Как видно разница в производительности в три раза в пользу штатного варианта.
Как видно разница в производительности в три раза в пользу штатного варианта.А оригинальный вариант от fxsaber показывает преимущество GetBid, или дело в более мощном/менее нагруженном ПК?
А оригинальный вариант от fxsaber показывает преимущество GetBid, или дело в более мощном/менее нагруженном ПК?
Его вариант у меня тоже показывал преимущество GetBid при полной загрузке процессора. Но при этом мой вариант показывает при той же загрузке показывает трехкратное преимущество штатной функции.
Это происходит потому, что мой вариант учитывает среднее время всех итераций получения цены Bid, а его только лишь мизерной части с аномальным зависанием.
Кто ж его знает по какой причине процессор в трудную для него "минуту" забивает именно на штатную функцию (когда задержка более 100 µ). Но все равно среднее время в три раза меньше для штатной функции
Ну и вот, например при if (Interval##A > 100) у меня такая картина:
тогда как при if (Interval##A > 0) уже совсем другая, показывающая случайные распределение аномальных задержек между штатным и альтернативным вариантом получения цены Bid
при этом мой тест при той же загрузки процессора показывает:
Поэтому, считаю, что вариант теста fxsaber далек от объективности.
Процессор загружал не агентами, а этим скриптом. Получалось более эффективно.
после небольшой модификации теста fxsaber, чтобы наглядно продемонстрировать, какой процент итераций учитывается в расчетах:
т.е. примерно 0.01%
еще бы.
Если при среднем времени выполнения SymbolInfoDouble(_Symbol, SYMBOL_BID) около 50 наносекунд, учитываются только те, выполнение которых более 100 000 наносекунд.
после небольшой модификации теста fxsaber, чтобы наглядно продемонстрировать, какой процент итераций учитывается в расчетах:
т.е. примерно 0.01%
еще бы.
Если при среднем времени выполнения SymbolInfoDouble(_Symbol, SYMBOL_BID) около 50 наносекунд, учитываются только те, выполнение которых более 100 000 наносекунд.
Можно было бы просто условие сделать не более 100 мкс, а более 3 мкс. Результат видимо был тот же. Мысль была что сегментарное исследование и в разных условиях исполнения может быть разница в разных сегментах и на разных участках противоположная. Приоритеты исполнения часто делают в зависимости от чего либо. При легкой нагрузке одни приоритеты, при большой другие, при критических, те которые на дают компу зависнуть и рухнуть, и производительность уходит на второй план.
Вообще торговля при загрузке более 70% железа это не правильно. Это почти критическое исполнение. Загрузка железа на боевых советниках должна быть не более 60%.
а HFT-брокеры у вас уже есть?)
попробуйте протестировать SymbolInfoTick когда в обзоре рынка один символ и когда несколько десятков символов, но запрашивайте один инструмент - как в Вашем примере
высока вероятность, что с сервера идет сжатый трафик и эти периодические тормоза SymbolInfoTick появляются когда происходит распаковка данных
т.е. когда много символов будет еще более частые или глубокие провалы во времени теста
В последних сборках прием потока тиков не влияет даже теоретически. Практически SymbolInfoTick уже сейчас работает с кэшом, но отдельные граждане продолжают искать черную кошку.
А у него в тесте и не 80% даже. Там 6 агентов пашут на 4 ядрах, т.е. гарантировано 100%.
Вопрос только в том, как справляется с этой ситуаций планировщик задач его системы. При этом делаются утверждения, что виновата именно реализация терминала.
Т.е. искусственно создается ситуация, когда компьютер загружен сверх всякой меры, когда на нем тормозит буквально всё, а потом делаются заявления в стиле "ой, смотрите, а почему это вот там терминал иногда имеет лаги".
Закроем глаза, что даже в таких условиях это "примерно 0.01%" - к черту подробности! Достаточно заявить, что "средняя температура по больнице никого не волнует", "лаги создают проблемы во время торговли" и "хотим HFT".
Более того, конечно же, хотим чтобы HFT был в 20 экспертов на старом офисном десктопе или дохлой виртуалке.
PS PositionSelectByTicket() в своей реализации безусловно имеет доступ к разделяемому ресурсу с синхронизацией доступа. А если не селектить позицию на каждом вызове, то вы читаете старую цену. Проще было сделать "снепшот" через SymbolInfoDouble.