記事"MQL5とQLUAの比較ーなぜMQL5での取引操作は28倍速いのか?"についてのディスカッション - ページ 3

新しいコメント
 
Renat Fatkhullin:

同時に、10％のような測定値の差がある場合である。

しかし、数十回のテスト結果によると、4～5倍の安定した差がある場合、議論することはありません。

MT5での差（安定していない）は最大2倍だった。そのため、パフォーマンスを測定するのであれば、パケットが到着する最大頻度（隣接するパケット間の最小時間）を見るべきだと考えた。それに対応するExpert Advisorを書いてみた。

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

  static string ToString( const int Interval, const datetime ServerTime )
  {
    return("Frequency = " + ((Interval == 0) ? "Unknown" : ::DoubleToString(1 e6 / 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

隣り合うBookEventイベントの間隔が～10msであれば、妥当である。しかし、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

これは、ティックパケットが到着すると、そのティックパケットから 一定の間隔と数（開発者が設定）で ティックイベントが生成される ことでしか説明できません。こうすることで、Expert Advisorで近いティックを見逃すことがなくなります。


Calculate-eventsに関しては、コードをインジケーターに変換したため、Calculate-events間の最大頻度はTick-eventsよりもはるかに高くなっています。これは、パッケージ内のすべてのティックに対して Calculate-event が作成されるためです。

そのため、この測定実装はTick/Calculate/BookEventイベントには適していません。また、MQL5で新しいクォート・ネットワーク・パケットの到着を監視する方法はまだ明らかになっていません。

 
Renat Fatkhullin:

どのようなテストでも、コールドスタートに対するプロテクションが含まれていなければならない。

つまり、N目盛りをスキップすることは、この事実を認識し、それを考慮していることを示す指標となる。ただ、明らかに予想される「なぜコールドスタートの影響を補正しなかったのか」というクレームを避けるためである。


3つの端末のセッション開始に関する ビデオは、セッション開始時にMT5が遅くなると主張するトレーダーの別の主張のために2016年8月25日に用意されました。後に判明したことだが、このトレーダーはMT5をまったく使用しておらず、フォーラムからの憶測を放送したものだった。また、一部のトレーダーは、為替商品のチャートがビッドではなく、取引された最終価格によって構築されることを認識していないことも判明した。彼らは、ビッドを変更してチャートに表示しないことを「MT5のブレーキ」と認識していた。

もちろん、ブレーキはありません。

ありがとうございます！
 
fxsaber:

MT5での差（安定しない）は最大2倍だった。そこで、パフォーマンスを測定するのであれば、パケットが到着する最大頻度（隣り合うパケット間の最短時間）を見るべきだと考えた。それに対応するExpert Advisorを書いてみた。

その結果

隣り合うBookEventイベントの間隔が～10msであれば、妥当である。しかし、0.035msは妥当ではない。BookEventはTickイベントと同じ原理で作られることがわかった：

もっともらしい。

データはトランザクションごとにやってきます。短いタイミングで2つの連続したトランザクションを見たという事実は、私たちの処理の正しさと、端末そのものとMQL5サブシステムの両方のパフォーマンスの大きな証明です。


したがって、この測定方法はTick/Calculate/BookEventイベントには適していません。また、MQL5で新しいクォート・ネットワーク・パケットの到着をモニターする方法はまだ明らかになっていません。

非常に適しています。

私たちのコードを見てください - それは特に単一の短いデータを測定するのではなく、愚かにも30秒間のティックを収集します。これにより、変動やエラーが平準化されます。

上のビデオでは、MQL5が30秒間に1,278ティックを受信したのに対し、QLUAは254ティックしか受信していない。これはQLUAのアルゴトレーディングにとって残酷なことだ。

 
Renat Fatkhullin:

もっともです。

データはトランザクションでやってくる。短いタイミングで2つの連続したトランザクションを見たという事実は、我々の処理の正しさと、端末とMQL5サブシステムの両方のパフォーマンスの大きな証明である。

しかし、それらはネットワーク・パケットのパケットでやってきた。ゲートウェイのスピードを測りたい。

ぴったりだ。

私たちのコードを見てください。特別に単一の短いデータではなく、30秒間の刻みを愚直に集めて測定しています。これによって揺らぎや誤差が平準化される。

上のビデオでは、MQL5が30秒間で1,278ティックを受信したのに対し、QLUAは254ティックしか受信していない。これはQLUAのアルゴトレーディングにとって残酷なことだ。

あなたは私の言いたいことを理解していない。私はQLUAのブレークについて何も気にしていない。私はMT5自体のパフォーマンス特性を知りたいのです。そして、私が実装したMaxFrequency-wayだけでは適合しない。なぜなら、MT5はTick/Calculate/BookEventイベントの作成に特殊性があるからだ。Expert Advisorをあなたの場所で実行してみてください。
 
fxsaber:

しかし、それらはネットワーク・パケットに束になって入ってきた。ゲートウェイの速度を測定したいのですが。

それは問題ではない。

ただ、ティックが次から次へとやってきて、MT5ターミナルはそれをうまく、ブレーキなしで渡すことができた。


あなたは私を誤解している。私はQLUAのブレーキなど気にしていない。私はMT5自体のパフォーマンス特性を知りたいのです。そして、私が実装したMaxFrequency-wayだけでは適合しません。なぜなら、MT5はTick/Calculate/BookEventイベントの作成に特殊性があるからだ。Expert Advisorをあなたの場所で実行してみてください。

各ティックは 独立して送信されるトランザクションである」という原則は、観念的にはすべてが正しく構築されていることを意味します。私たちは5つのプラットフォームをゼロから構築し、すべての落とし穴を何度も経験しました。

あなたは非常に高いパフォーマンスを手に入れた。頻度を作り始めたことは明らかにナンセンスだ。データがあるときはデータがある。だから、「周波数の安定性／不安定性」について話すことは論理的に意味がない。あなたは水晶発振器の安定性をテストしているのではなく、ガラスに価格が現れるランダムなプロセスを安定させようとしているのです。

元々、スナップショット周波数の制御の上にすべてのプロセスを構築したのはクイックに過ぎない。当然の結果だ。

 
Renat Fatkhullin:

そんなことはどうでもいい。

ティックが次から次へと送られてくるだけで、MT5ターミナルはそれをうまく、ブレーキなしに渡すことができる。


各ティックは独立して送信されたトランザクションである」という原則は、観念的にすべてが正しく構築されていることを意味します。そして、私たちがゼロから5つのプラットフォームを構築し、すべての落とし穴を何度も経験したのであれば、それが間違っているはずがありません。

あなたは非常に高いパフォーマンスを手に入れた。頻度を作り始めたことは明らかにナンセンスだ。データがあるときはデータがある。だから、「周波数の安定性／不安定性」について話すことは論理的に意味がない。あなたは水晶発振器の安定性をテストしているのではなく、ガラスに価格が現れるランダムなプロセスを安定させようとしているのです。

周波数の原理は簡単に説明できる。スタックは取引所自身によって不安定な速度で形成される。

私は、スタック更新の 最大頻度、つまりMT5が単位時間当たりに生成できるスタックの数を測定したかったのです。スタックは MT5 にパッケージで送られてくることがわかりました。取引所からのスタックが失われることもなく、すべて来る可能性もあります。そして、BookEventイベントは、パッケージに対してではなく、パッケージ内のすべての賭け金（最も古いものから最新のものまで）に対して作成されます。MQL5ではスタック形成時刻を取得することは不可能である。パッケージの到着時刻は同じです。したがって、対応するMT5のパフォーマンス特性を測定する私の実装では、私が見たいものが表示されないことが判明しました。

BookEventがパケットで形成されるという事実を、私は全身全霊で支持します。Expert Advisorにとって最大限の情報と最小限の手間です。パフォーマンス測定に関する唯一の問題は、私が説明したことです。

 
fxsaber:

頻度の原理は簡単に説明できる。スタックは、市場参加者のアクションに依存するため、取引所自体によって可変速度で形成されます。

私は、スタック更新の最大頻度、つまりMT5が単位時間当たりに生成できるスタックの数を測定したいと考えました。スタックは MT5 にパッケージで送られてくることが判明しました。取引所からのスタックが失われることもなく、すべて来る可能性もあります。そして、BookEventイベントは、パッケージに対してではなく、パッケージ内のすべての賭け金（最も古いものから最新のものまで）に対して作成されます。MQL5ではスタック形成時刻を取得することは不可能である。パッケージの到着時刻は同じです。したがって、対応するMT5のパフォーマンス特性を測定する私の実装では、私が見たいものが表示されないことが判明しました。

BookEventがパケットで形成されるという事実を、私は全身全霊で支持します。Expert Advisorにとっては最大限の情報と最小限の手間です。しかし、パフォーマンス測定には私が説明したような問題点しかない。

もう一度言いますが、このような方法で頻度を測定し、そのような結論を出すのは意味がありません。

2ティック間の時間差に基づいて、スタック内の価格出現のランダムなプロセスの頻度を測定しようとしないでください。1からXXXXXまでの数字が乱高下するのは明らかです。

あなたは間違った質問をし、間違った計算をし、間違った結論を出した。同時に、あなたは「MT5は見たいものを表示しない、測定できない」という発言で籐に影を落としています。

パフォーマンス測定」に問題はない。なぜなら、あなたは間違ったものを間違った方法で測定したからだ。あなたは間違った特性を導き出し、根本的に間違った計算をしたのです。


ps:しかし、テストでは、我々は30秒間引用を収集し、滞在時間で割ることによって、正しく引用の到着頻度を測定した。

 
Renat Fatkhullin:

もう一度言いますが、このような方法で頻度を測定し、このような結論を出すことは意味がありません。

2つのティック間の時間差に基づいて、ガラスに価格が出現するランダムなプロセスの頻度を測定しようとしないでください。1からXXXXXまでの数字が乱高下するのは明らかです。

あなたは間違った質問をし、間違った計算をし、間違った結論を出しています。同時に、あなたは「MT5はあなたが見たいものを表示しない、測定できない」という発言で籐に影を落としています。

ps: しかし、私たちは、30秒間気配値を収集し、滞在時間で割ることによって、テストにおいて正しく気配値の到着頻度を測定しました。

私は現在の頻度ではなく、最大頻度を測定しています！私はこのような測定の理由、結果、ソースを詳細に説明しました。なぜかあなたは、私がMT5に影を落としていると感じている。

この議論を読んでいるフォーラムの古参者なら、私が何を言いたかったのか理解するだろう。そして、MT5に影を落としているなどとは思わないだろう。私の実装は間違っていたことが判明した。あなたのものではなく、私のものだ！あなたは、私が理由さえ述べていないところで、自分自身を弁護している。

あなたが望むものを測定できないのは、私の実装のせいです。MQL5にはそのような可能性はないし、それが普通だ。私がジュースを飲みたいのは普通だが、MQL5にはそのような機会がないのと同じだ。

対応するイベントの隣接する呼び出しの間の時間を測定し、それをパフォーマンスとして解釈したい人がいるならば、という結果だけを共有した。実際に何が表示されるのかを明確に認識する必要がある。

 

あなたは根本的に間違っている。

2つのイベントのデルタが0であるランダムなプロセスのデルタを実際に測定する場合、最大周波数は何ですか？

もしティックデリバリーが正しく実装されていれば（そして我々は正しく実装している）、明らかに最大 "頻度"=（プログラムコードによるMQL5コールの処理時間）/（タイマーエラー）が得られます。

理論的には、タイマーの精度を満たして0マイクロ秒になれば、周波数は無限大になる。また、ゼロによる除算の誤差は致命的 です（あなたのコードではゼロによる除算を制御できません）。

 
Renat Fatkhullin:

あなたは根本的に間違っている。

2つのイベントのデルタが0であるランダムなプロセスのデルタを実際に測定する場合、最大周波数は何ですか？

もしティックデリバリーが正しく実装されていれば（そして我々はそれを正しく実装している）、間違いなく最大 "頻度"=（プログラムコードによるMQL5コールの処理時間）/（タイマーエラー）が得られます。

そうです。ランダムなプロセスを計測していることが判明したので、ネットワークパケットの配送プロセスを計測しようと思った。しかし、うまくいかなかった。

理論的には、タイマーの精度を満たして0マイクロ秒を得ることができれば、周波数は無限大になる。まあ、それと致命的な ゼロ除算エラー（コードにゼロ除算制御がないん ですね）。

そうですね！
1234567
新しいコメント