Обсуждение статьи "Сравнение MQL5 и QLUA - почему торговые операции в MQL5 до 28 раз быстрее?" - страница 3

Новый комментарий
 
Renat Fatkhullin:

Одновременно, это когда у вас разница в замерах плавает как 10%.

А вот когда по результатам десятков тестов у вас разница стабильно в 4-5 раз, то обсуждать уже нечего.

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

class FREQUENCY
{
private:
  ulong PrevTime;
  int MinInterval;
  datetime TimeMinInterval;

  static string ToString( const int Interval, const datetime ServerTime )
  {
    return("Frequency = " + ((Interval == 0) ? "Unknown" : ::DoubleToString(1e6 / Interval, 1)) +
           " Hz (" + ::DoubleToString(Interval / 1000.0, 3) + " ms), ServerTime = " + (string)ServerTime);
  }

public:
  const string symbol;

  FREQUENCY( const string Symb = NULL ) :
         symbol((Symb == NULL) ? ::Symbol() : Symb), MinInterval(INT_MAX), PrevTime(0)
  {
  }

  ~FREQUENCY( void )
  {
    ::Comment("");
  }

  void Refresh( const string Symb )
  {
    if (Symb == this.symbol)
    {
      const ulong NowTime = ::GetMicrosecondCount();

      if (this.MinInterval == INT_MAX)
        this.MinInterval--;
      else
      {
        const int Interval = (int)(NowTime - this.PrevTime);

        if (Interval < this.MinInterval)
        {
          this.MinInterval = Interval;
          this.TimeMinInterval = ::TimeCurrent();

          ::Alert(this.ToString());
        }

        ::Comment(FREQUENCY::ToString(Interval, ::TimeCurrent()) + "\n" + this.ToString());
      }

      this.PrevTime = NowTime;
    }

    return;
  }

  string ToString( void ) const
  {
    return("Max" + FREQUENCY::ToString(this.MinInterval, this.TimeMinInterval) +
           ", ServerName = " + ::AccountInfoString(ACCOUNT_SERVER) + ", Symbol = " + this.symbol);
  }
};

class FREQUENCY_BOOK : public FREQUENCY
{
public:
  FREQUENCY_BOOK( const string Symb = NULL ) : FREQUENCY(Symb)
  {
    ::MarketBookAdd(this.symbol);
  }

  ~FREQUENCY_BOOK( void )
  {
    ::MarketBookRelease(this.symbol);
  }
};
/*
FREQUENCY Frequency;

void OnTick( void )
{
  Frequency.Refresh(_Symbol);

  return;
}
*/

FREQUENCY_BOOK FrequencyBook;

void OnBookEvent( const string &symbol )
{
  FrequencyBook.Refresh(symbol);

  return;
}

 И получил результат

2016.09.14 10:21:47.059 Frequency (Si-9.16,M1)  MaxFrequency = 28571.4 Hz (0.035 ms), ServerTime = 2016.09.14 10:21:28, ServerName = BCS-MetaTrader5, Symbol = Si-9.16
2016.09.14 10:21:47.014 Frequency (Si-9.16,M1)  MaxFrequency = 6211.2 Hz (0.161 ms), ServerTime = 2016.09.14 10:21:28, ServerName = BCS-MetaTrader5, Symbol = Si-9.16
2016.09.14 10:21:40.062 Frequency (Si-9.16,M1)  MaxFrequency = 5988.0 Hz (0.167 ms), ServerTime = 2016.09.14 10:21:21, ServerName = BCS-MetaTrader5, Symbol = Si-9.16
2016.09.14 10:21:35.199 Frequency (Si-9.16,M1)  MaxFrequency = 1242.2 Hz (0.805 ms), ServerTime = 2016.09.14 10:21:16, ServerName = BCS-MetaTrader5, Symbol = Si-9.16
2016.09.14 10:21:35.149 Frequency (Si-9.16,M1)  MaxFrequency = 222.9 Hz (4.486 ms), ServerTime = 2016.09.14 10:21:16, ServerName = BCS-MetaTrader5, Symbol = Si-9.16
2016.09.14 10:21:34.459 Frequency (Si-9.16,M1)  MaxFrequency = 122.0 Hz (8.200 ms), ServerTime = 2016.09.14 10:21:15, ServerName = BCS-MetaTrader5, Symbol = Si-9.16
2016.09.14 10:21:28.640 Frequency (Si-9.16,M1)  MaxFrequency = 120.7 Hz (8.286 ms), ServerTime = 2016.09.14 10:21:09, ServerName = BCS-MetaTrader5, Symbol = Si-9.16
2016.09.14 10:21:25.602 Frequency (Si-9.16,M1)  MaxFrequency = 115.2 Hz (8.684 ms), ServerTime = 2016.09.14 10:21:06, ServerName = BCS-MetaTrader5, Symbol = Si-9.16
2016.09.14 10:21:24.572 Frequency (Si-9.16,M1)  MaxFrequency = 106.7 Hz (9.373 ms), ServerTime = 2016.09.14 10:21:05, ServerName = BCS-MetaTrader5, Symbol = Si-9.16

И если ~10ms между соседними BookEvent-событиями - правдоподобно. То 0.035ms - нет. Выходит, что BookEvent-событие создается по тому же принципу, что и Tick-событие:

 Tick-событие наступает со сверх-огромной частотой:

MaxFrequency = 12820.5 Hz (0.078 ms), ServerTime = 2016.09.14 09:29:05, ServerName = RoboForexEU-MetaTrader 5, Symbol = EURUSD.e

Это можно объяснить только тем, что если приходит пакет с тиками, то Tick-событие генерируется для каждого тика из пакета в определенном интервале и количестве (задано разработчиками). Так получается не пропускать близко-расположенные тики в советниках.


Что касается Calculate-событий, то, переделав код в индикатор, максимальная частота между Calculate-событиями значительно превосходит оную для Tick-событий. Это связано с тем, что, похоже, Calculate-событие создается для ВСЕХ тиков в пакете.

 

Поэтому данная реализация измерения не подходит для Tick/Calculate/BookEvent-событий. И как мониторить приход нового котировочного сетевого пакета в MQL5 - пока не ясно.

 
Renat Fatkhullin:

Любой тест должен содержать защиту от cold старта.

Поэтому пропуск N тиков - это показатель, что мы знаем и учитываем это обстоятельство. Просто чтобы избежать заведомо ожидаемой претензии "почему вы не компенсировали влияние cold старта".


Видео про старт сессии трех терминалов было подготовлено 25 августа 2016 для другой претензии трейдера, который утверждал, что МТ5 тормозит на старте сессии. Как в последствии оказалось, этот трейдер вообще не использовал МТ5, а транслировал домыслы с форума. Также выяснилось, что некоторые трейдеры не были в курсе, что для биржевых инструментов графики строятся не по Bid, а по проторгованным Last ценам. Изменение бидов с непоказом их на чартах они воспринимали как "тормоза МТ5".

Конечно, никаких тормозов нет.

Спасибо, теперь понятно!
 
fxsaber:

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

 И получил результат

И если ~10ms между соседними BookEvent-событиями - правдоподобно. То 0.035ms - нет. Выходит, что BookEvent-событие создается по тому же принципу, что и Tick-событие:

Правдоподобно.

Данные приходят транзакционно и то, что вы увидели две последовательные транзакции с коротким таймингом - это отличное доказательство правильности нашего процессинга и производительности как самого терминала, так и подсистемы MQL5.


Поэтому данный способ измерения не подходит для Tick/Calculate/BookEvent-событий. И как мониторить приход нового котировочного сетевого пакета в MQL5 - пока не ясно.

Еще как подходит.

Посмотрите на наш код - он специально замеряет не единичные короткие данные, а тупо собирает тики за 30 секунд. Это нивелирует любые флуктуации и любые погрешности.

В указанном видео за 30 сек MQL5 получил 1 278 тиков, а QLUA всего 254 тика. Это жесточайший облом для алготрейдинга в QLUA.

 
Renat Fatkhullin:

Правдоподобно.

Данные приходят транзакционно и то, что вы увидели две последовательные транзакции с коротким таймингом - это отличное доказательство правильности нашего процессинга и производительности как самого терминала, так и подсистемы MQL5.

Но пришли они пачкой в сетевом пакете. Хочу же замерить скорость шлюза.

Еще как подходит.

Посмотрите на наш код - он специально замеряет не единичные короткие данные, а тупо собирает тики за 30 секунд. Это нивелирует любые флуктуации и любые погрешности.

В указанном видео за 30 сек MQL5 получил 1 278 тиков, а QLUA всего 254 тика. Это жесточайший облом для алготрейдинга в QLUA.

Вы не поняли меня. QLUA-тормоз никак не волнует - с ним все ясно (и к статье вопросов нет). Хочется получить performance-характеристики самого MT5. И как раз MaxFrequency-способ, как реализовал, не подошел. Т.к. в MT5 есть особенность с созданием Tick/Calculate/BookEvent-событий. Запустите советник у себя - увидите воочию очень быстро.
 
fxsaber:

Но пришли они пачкой в сетевом пакете. Хочу же замерить скорость шлюза.

Не важно.

Просто тики пришли друг за другом, а МТ5 терминал умудрился их красиво и без тормозов отдать вам.


Вы не поняли меня. QLUA-тормоз никак не волнует - с ним все ясно (и к статье вопросов нет). Хочется получить performance-характеристики самого MT5. И как раз MaxFrequency-способ, как реализовал, не подошел. Т.к. в MT5 есть особенность с созданием Tick/Calculate/BookEvent-событий. Запустите советник у себя - увидите воочию очень быстро.

Принцип "каждый тик - это транзакция, посылаемая независимо" означает, что идеологически все построено правильно. Да и как может быть неправильно, если мы с нуля построили 5 платформ и прошлись по всем граблям не один раз.

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

Это как раз Квик исходно у себя все процессы построил на контроле частоты снапшотов. С закономерным результатом.

 
Renat Fatkhullin:

Не важно.

Просто тики пришли друг за другом, а МТ5 терминал умудрился их красиво и без тормозов отдать вам.


Принцип "каждый тик - это транзакция, посылаемая независимо" означает, что идеологически все построено правильно. Да и как может быть неправильно, если мы с нуля построили 5 платформ и прошлись по всем граблям не один раз.

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

Принцип частоты могу легко объяснить. Стакан формируется самой биржей с непостоянной скоростью, т.к. зависит от действий участников рынка.

Хотел замерить, какова максимальная частота обновления стакана - сколько максимально стаканов может выдать MT5 в единицу времени. Оказалось, что стаканы приходят в MT5 пакетами. Возможно, что стаканы от биржи даже не теряются, а приходят вообще ВСЕ. И BookEvent-событие создается не для пакета, а для всех стаканов в пакете (от более раннего до самого позднего). Время формирования биржей стакана в MQL5 невозможно получить. Время прихода пакета - аналогично. Поэтому получается, что моя реализация замера соответствующей характеристики производительности MT5 не показывает то, что хочется увидеть.

То, что BookEvent формируется пачками - поддерживаю всеми конечностями. Это максимум инфы и минимум геморроя для советника. Вот только с замером производительностью проблема, что описал.

 
fxsaber:

Принцип частоты могу легко объяснить. Стакан формируется самой биржей с непостоянной скоростью, т.к. зависит от действий участников рынка.

Хотел замерить, какова максимальная частота обновления стакана - сколько максимально стаканов может выдать MT5 в единицу времени. Оказалось, что стаканы приходят в MT5 пакетами. Возможно, что стаканы от биржи даже не теряются, а приходят вообще ВСЕ. И BookEvent-событие создается не для пакета, а для всех стаканов в пакете (от более раннего до самого позднего). Время формирования биржей стакана в MQL5 невозможно получить. Время прихода пакета - аналогично. Поэтому получается, что моя реализация замера соответствующей характеристики производительности MT5 не показывает то, что хочется увидеть.

То, что BookEvent формируется пачками - поддерживаю всеми конечностями. Это максимум инфы и минимум геморроя для советника. Вот только с замером производительностью проблема, что описал.

Еще раз повторю - не имеет смысла так замерять частоту и делать такие выводы.

Не пытайтесь замерить частоту рандомного процесса появления цен в стакане на основе разницы во времени между двумя тиками. Вы заведомо получите дикий разброс цифр от 1 до XXXXX.

Вы поставили неправильный вопрос, неправильно подсчитали и сделали неправильные выводы. Заодно тень на плетень навели заявлениями "МТ5 не показывает что хочется увидеть, нельзя замерить".

Никакой проблемы "замера производительности" нет, так как вы совсем не то и не так замеряли. Сами придумали неправильную характеристику и принципиально неправильно посчитали.


ps: а вот мы в тестах частоту прихода котировок замерили правильно путем сбора котировок за 30 сек и поделив на затраченное время.

 
Renat Fatkhullin:

Еще раз повторю - не имеет смысла так замерять частоту и делать такие выводы.

Не пытайтесь замерить частоту рандомного процесса появления цен в стакане на основе разницы во времени между двумя тиками. Вы заведомо получите дикий разброс цифр от 1 до XXXXX.

Вы поставили неправильный вопрос, неправильно подсчитали и сделали неправильные выводы. Заодно тень на плетень навели заявлениями "МТ5 не показывает что хочется увидеть, нельзя замерить".

ps: а вот мы в тестах частоту прихода котировок замерили правильно путем сбора котировок за 30 сек и поделив на затраченное время.

Я замеряю МАКСИМАЛЬНУЮ частоту, а не текущую! Очень подробно описал причину таких замеров, результаты и дал исходник. Вам почему-то кажется, что я набрасываю тень на MT5.

Любой старичек форума, кто прочтет это обсуждение, поймет, что я имел в виду. И не увидит ни тени в сторону MT5. Моя реализация оказалась неправильной. Моя, не Ваша! Что Вы обороняетесь там, где даже повода не давал.

Именно моя реализация не дает возможности замерить то, что хочется. В MQL5 такой возможности нет и это нормально. Как нормально и то, что мне хочется сока, но MQL5 такой возможности не дает.

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

 

Вы в корне неправы.

Какая еще максимальная частота, когда вы по факту собрались мерять дельту рандомного процесса, у которого два события запросто имеют дельту 0?

Если доставка тиков реализована правильно (а у нас она правильная), то вы заведомо получите в максимуме "частоту" = (время отработки MQL5 вызова с кодом программы) / (погрешность таймера).

Теоретически, если уложиться в точность таймера и получить 0 микросекунд, то частота будет бесконечность. Ну и критическая ошибка деления на ноль (у вас в коде нет контроля деления на ноль).

 
Renat Fatkhullin:

Вы в корне неправы.

Какая еще максимальная частота, когда вы по факту собрались мерять дельту рандомного процесса, у которого два события запросто имеют дельту 0?

Если доставка тиков реализована правильно (а у нас она правильная), то вы заведомо получите в максимуме "частоту" = (время отработки MQL5 вызова с кодом программы) / (погрешность таймера).

Да, так и получаю. Получилось, что рандомный процесс у меня замеряется, а я хотел процесс доставки сетевых пакетов замерить. Но не вышло.

Теоретически, если уложиться в точность таймера и получить 0 микросекунд, то частота будет бесконечность. Ну и критическая ошибка деления на ноль (у вас в коде нет контроля деления на ноль).

Есть!
1234567
Новый комментарий