ライブラリ: TesterBenchmark - ページ 3

新しいコメント
 
Andrey Khatimlianskii:

Vasily、テスターと実際のOrderSendの実行速度の比較可能性について真剣に話しているのですか？

オンラインではサーバーに情報を送信して応答を待つので最も遅いですが、テスターでは（遅延を含めなければですが、問題外でした）送信も待機も瞬時に行われます。

このライブラリの仕事は、テスターの（取引機能面での）速度を測定することだけである。

はい、考えていませんでした。私のミスです。具体的には、OrderSendはテスターではもっと 速く動作します。しかし、やはりテスト時間の大部分はシステム機能に食われています。MT5では、MT4と違って、取引環境の完全なシミュレーションがあるからです。そのため、パイプラインが16%高速化されたとしても、パイプラインにかかる時間は全体の5%の16%に過ぎない。つまり、MT5でコードを最適化 するというアイデアは、非常に崇高ではあるが無意味である。

 
Vasiliy Sokolov:

ああ、考えてなかった。私のミスです。OrderSendはテスターではもっと 速く動きます。しかし、やはりテスト時間の大部分はシステム機能に費やされると思います。MT5では、MT4と違って、取引環境の完全なシミュレーションがあるからです。そのため、パイプラインが16%高速化されたとしても、パイプラインにかかる時間は全体の5%の16%に過ぎない。つまり、MT5におけるコードの最適化という アイデアは、非常に崇高ではあるが無意味である。

最後の意見には同意できない。

fxsaberの研究のおかげで、MT5は すでに 取引履歴の作業を桁違いに高速化しています。

 
Andrey Khatimlianskii:

最後の発言には同意できない。

fxsaberの研究のおかげで、MT5は取引履歴を扱う上で すでに桁違いに 高速です。

議論しているわけではありません。Fxsaberは言語とコミュニティ全般の発展に大いに貢献している。彼は正しいことをしている。MT5には多くのエラーがあり、誰かがそれを見つけるのは素晴らしいことだ。しかし、作業速度が桁違いに低下するMT5の作業における重大なエラーと、SBコードのノミ捕りを混同してはならない。リブを高速化することは確かに可能であり、必要でさえある。しかし、そこに重大なエラーがなければ、桁違いの高速化は起こらない。

 
Vasiliy Sokolov:

議論しているわけではない。Fxsaberは言語やコミュニティ全体に多くの貢献をしている。彼は正しいことをしている。MT5には多くのエラーがあり、誰かがそれを見つけることは素晴らしいことだ。しかし、作業速度が桁違いに低下するMT5の作業における重大なエラーと、SBコードのノミ捕りを混同してはならない。リブを高速化することは確かに可能であり、必要でさえある。しかし、そこに重大なエラーがなければ、桁違いの高速化はありえない。

SBについては考えたこともない。

比較のために手元に来ただけだと思う。

 
Andrey Khatimlianskii:

最後の発言には同意できない。

fxsaberの研究のおかげで、MT5は すでに 取引履歴の作業を桁違いに加速している。

ところで、ところで、2013年に取引履歴が めちゃくちゃになりました。そのとき、以下のコードがリニアに動作しないことに気づいたのを覚えている：

int total = HistoryDealsTotal();
for(int i = 0; i < total; i++)
{
   ulong ticket = HistoryDealTicket(i);
   HistoryDealSelect(ticket);
}

つまり、iが大きくなればなるほど、HistoryDealSelectの動作は遅くなる。遅さは指数関数的だった。そのため、私はこの速度低下のグラフをエクセルで作成し、サービスデスクと連絡を取らなければなりませんでした。そう、バグがあったし、これからもあるだろう。

 

今、私はOrderSendをOrderSendAsynchに 変更することで、コードを少し微調整しました。結果は予想通り違った：

時間の85％がHistorySelectに費やされている。つまり、システムコールに戻ったが、少し違う。

 
ライブラリはこの目的のために書かれた
異なるバージョンのコードを記述する場合、テスターでExpert Advisorの全体的なパフォーマンスへの影響を測定する必要があるかもしれません。これにより、記述したコードが他のコードと比較してどの程度最適であるかを理解できるだけでなく、将来Expert Advisorを迅速に最適化するための前提条件を提供することができます。このアプローチにより、EAのパフォーマンスにおける「ボトルネック」を特定することができます。

また、このアプローチはMT4Orders.mqhだけでなく、Trade.mqhでも機能しました。また、ライブラリを使用した結果、他のいくつかのものも（特に）顕著に高速化することができました。

健全で合理的なソリューションなど。

事実 - 最適化までの時間は、コードの書き方に大きく依存します。このライブラリは、私自身だけでなく、他の人たちの注意を喚起するのに便利だった。

一例として（作者のお許しがありますように）、kodobaseには、少なくとも使用されている取引ライブラリの せいで、パフォーマンスの面ではOptimiserで輝かないEAがたくさんあります。実際、スマートで強力なOOPアドバイザーがMT5テスターのスピード能力をすべて否定する場合、これはkodobase（そしてきっとMarket）のある種の災いですらあります。

ほとんど何もテスターのために書かれていないようです。そして、これはTSで作業する際の大きな要素です。

 
fxsaber:

...スマートで強力なOOPアドバイザーがMT5テスターのすべてのスピード機能を無効にする場合。

あなたの例のプロファイリングをもう一度見てみましょう。すべてがHistorySelect(0, TimeCurrent)によって妨げられています。OOPでは、HistorySelectの呼び出しをバイパスすることができ、純粋なMQL5関数の呼び出しに比べてプログラムの実行 時間が大幅に短縮されます。OOPがMT5のすべてのスピード機能を無効にするという記述は間違っています。場合によっては、HistorySelectの場合のように、OOPのおかげで逆にスピードアップできることもあります。

 
Vasiliy Sokolov:

あなたの例のプロファイリングをもう一度見てください。すべてがHistorySelect(0, TimeCurrent)によって妨げられています。OOPでは、HistorySelectの呼び出しをバイパスすることが可能であり、純粋なMQL5関数の呼び出しに比べてプログラムの実行 時間が大幅に短縮されます。OOPがMT5のすべてのスピード機能を無効にするという記述は間違っています。HistorySelectの場合のように、OOPのおかげで逆にスピードアップできる場合もあります。

なぜか、HistorySelectは未決済のポジションがないときにのみ呼び出されることに気づかない。しかも、その直後に新しいポジションがオープンされる。つまり、ヒストリーが呼び出されることは非常に稀なのだ。テスターの時間が実装によって異なるのは事実です（少なくともログの時間を確認してください）。


私はすべてをOOPで書いているが、その遅さをほのめかしたことはない。特にOOPに熱心な作者の大半は、時にとても便利で美しいデザインを作ります。しかし、彼らはそのソリューションのパフォーマンスには注意を払わない。そしてこれはテスターにとって非常に重要なことです。誰もが自分のEAを何時間も速く（あるいはクラウドで安く）最適化したいと考えている。長く書かれ、自動的にプラグイン可能なOOPモジュールにボトルネックがあることはよくあることだ。しかし、もちろん誰もそれに気づきません。


使用されている取引APIのパフォーマンスを表示する独自のExpert Advisorを書くことができます。例えば、オリジナルのものから履歴アクセスやロット計算を削除する。

 
fxsaber:

使用する取引APIのパフォーマンスを表示する独自のExpert Advisorを書くことができます。例えば、オリジナルのものから履歴アクセスやロット計算を捨てます。

CStrategyでは、取引操作は CTradeを通じて直接行われます。つまり、CStrategyには独自の取引ロジックは一切ありません。テスト用Expert Advisorでは、N秒後にポジションをオープン/クローズする以外の取引ロジックは見当たりませんでした。CStrategy はヒストリカル・ポジションも保存しないので、この例は残念ながら CStrategy では実現できない。

fxsaber:

特にOOPに熱心な著者の大多数は、時に非常に便利で美しい構造を作ります。

OOPに情熱的な著者の大多数は、残念ながら原則的には存在しません。MetaQuotesのSB著者を含めても、リソース全体で5-10人のOOP著者しかいないかもしれません。私たちは少数で、シールの中にいます:)

fxsaber:

私はすべてをOOPで書いていますが、その遅さについてほのめかしたことはありません。特にOOPに熱心な著者の圧倒的多数は、時にとても便利で美しいデザインを作ります。しかし、彼らはそのソリューションのパフォーマンスには注意を払っていません。そしてこれはテスターにとって非常に重要なことです。誰もが自分のEAを何時間も速く（あるいはクラウドで安く）最適化したいと考えている。長く書かれ、自動的にプラグイン可能なOOPモジュールにボトルネックがあることはよくあることだ。しかし、もちろん誰もそれに気づかない。

OOPコードの実行速度が手続き型コードより遅いという事実は、私には何の意味もない。本題に入ろう：どのCTradeメソッドがボトルネックなのか？なぜか？これらのメソッドのプロファイリングは何を教えてくれますか？テスターで遅いコードセクションをどのように特定しますか？

1234
新しいコメント