MT5とスピードの関係 - ページ 16 1...91011121314151617181920212223...94 新しいコメント fxsaber 2020.08.27 10:15 #151 fxsaber:同じスクリプトを他の取引プラットフォームで比較するのも面白いかもしれませんね。 MT4 b1280です。 // Мониторинг длительных пиков выполнения важных функций для торговли. #include <fxsaber\Benchmark.mqh> // https://c.mql5.com/3/321/Benchmark.mqh input int inCycle = 10; // Циклов проверки в одном OnTick input int inAlertTime = 1; // Нижний порог в миллисекундах #define _B2(A) _B(A, AlertTime) void Check( const string Symb, const int AlertTime = 1 ) { MqlTick Tick; if (_B2(SymbolInfoTick(Symb, Tick))) { _B2(OrdersHistoryTotal()); _B2(OrdersTotal()); _B2(OrderSelect(0, SELECT_BY_POS)); _B2(OrderSelect(0, SELECT_BY_POS, MODE_HISTORY)); _B2(OrderSelect(0, SELECT_BY_TICKET)); _B2(GetLastError()); _B2(IsStopped()); _B2(SymbolInfoDouble(Symb, SYMBOL_ASK)); _B2(SymbolInfoDouble(Symb, SYMBOL_TRADE_TICK_VALUE)); _B2(SymbolInfoDouble(Symb, SYMBOL_POINT)); _B2(SymbolInfoInteger(Symb, SYMBOL_DIGITS)); _B2(TimeCurrent()); _B2(TimeLocal()); _B2(OrderGetDouble(ORDER_PRICE_CURRENT)); _B2(OrderGetInteger(ORDER_MAGIC)); _B2(OrderGetString(ORDER_SYMBOL)); _B2(AccountInfoDouble(ACCOUNT_EQUITY)); _B2(MQLInfoInteger(MQL_TRADE_ALLOWED)); _B2(AccountInfoInteger(ACCOUNT_TRADE_EXPERT)); _B2(AccountInfoInteger(ACCOUNT_TRADE_ALLOWED)); _B2(TerminalInfoInteger(TERMINAL_TRADE_ALLOWED)); _B2(SymbolsTotal(true)); _B2(SymbolName(0, true)); _B2(Symbol()); _B2(GlobalVariableCheck(NULL)); _B2(GlobalVariableGet(NULL)); _B2(ResourceFree(NULL)); } } void OnTick() { for (int i = 0; i < inCycle; i++) Check(_Symbol, inAlertTime); } 2020.08.27 13:09:46.799 Test6 EURUSD,M1: Alert: Time[Test6.mq4 39: AccountInfoInteger(ACCOUNT_TRADE_EXPERT)] = 7 ms. 2020.08.27 13:09:46.790 Test6 EURUSD,M1: Alert: Time[Test6.mq4 18: OrderSelect(0,SELECT_BY_POS,MODE_HISTORY)] = 2 ms. 2020.08.27 13:09:46.784 Test6 EURUSD,H1: Alert: Time[Test6.mq4 25: SymbolInfoDouble(Symb,SYMBOL_TRADE_TICK_VALUE)] = 1 ms. スリップは3回だけで、その後はほとんど飛び出すことはありませんでした。おそらくHistorySelectと CopyTicksがないのでブレーキを作るのは難しいでしょう。 Dmi3 2020.08.27 10:19 #152 Fast235:どちらもHaswellなので、xeonは動作周波数がかなり低く、パフォーマンスやシングルテストでは性能劣化が ありますが、マルチスレッドでの最適化だけは有利になります。最新機種のi3は、動作がかなり速くなるはずですキャッシュレベルの速度への影響や、Zen2や最新のIntelの速度については、開発者に聞いてみてください。つける私が持っているRyzen 3700xは、Intelでテストをすることができます。例えば、次のMQL5Scriptsのようなスクリプトを使用します。タイマーで何度もループさせる ここではテストの話ではなく、注文 実行の遅れの話をしています。この遅延があるから、浮いているんです。そして、TSも私もかなり悩まされます。 fxsaber 2020.08.27 10:19 #153 fxsaber:3つだけ出てきて、その後はほとんど出てきません。HistorySelectやCopyTicksがないので、ブレーキを作るのが大変なのでは? MT4でも待ってました。 2020.08.27 13:18:00.306 Test6 GBPCAD.rann,M1: Alert: Time[Test6.mq4 26: SymbolInfoDouble(Symb,SYMBOL_POINT)] = 1 ms. 2020.08.27 13:17:39.820 Test6 GBPCAD.rann,M1: Alert: Time[Test6.mq4 30: TimeLocal()] = 2 ms. 2020.08.27 13:17:32.598 Test6 GBPCAD.rann,M1: Alert: Time[Test6.mq4 30: TimeLocal()] = 36 ms. 2020.08.27 13:17:29.676 Test6 GBPCAD.rann,H1: Alert: Time[Test6.mq4 15: OrdersHistoryTotal()] = 1 ms. 2020.08.27 13:17:26.468 Test6 GBPCAD.rann,H1: Alert: Time[Test6.mq4 27: SymbolInfoInteger(Symb,SYMBOL_DIGITS)] = 5 ms. 2020.08.27 13:17:26.460 Test6 GBPCAD.rann,M1: Alert: Time[Test6.mq4 13: SymbolInfoTick(Symb,Tick)] = 1 ms. 2020.08.27 13:17:14.528 Test6 GBPCAD.rann,M1: Alert: Time[Test6.mq4 13: SymbolInfoTick(Symb,Tick)] = 3 ms. 2020.08.27 13:16:52.309 Test6 GBPCAD.rann,H1: Alert: Time[Test6.mq4 15: OrdersHistoryTotal()] = 2 ms. 2020.08.27 13:16:52.308 Test6 GBPCAD.rann,M1: Alert: Time[Test6.mq4 15: OrdersHistoryTotal()] = 2 ms. 2020.08.27 13:16:52.307 Test6 GBPCAD.rann,H1: Alert: Time[Test6.mq4 36: AccountInfoDouble(ACCOUNT_EQUITY)] = 1 ms. 2020.08.27 13:16:42.448 Test6 GBPCAD.rann,M1: Alert: Time[Test6.mq4 17: OrderSelect(0,SELECT_BY_POS)] = 2 ms. 2020.08.27 13:16:32.480 Test6 GBPCAD.rann,H1: Alert: Time[Test6.mq4 36: AccountInfoDouble(ACCOUNT_EQUITY)] = 3 ms. 2020.08.27 13:16:32.479 Test6 GBPCAD.rann,H1: Alert: Time[Test6.mq4 15: OrdersHistoryTotal()] = 3 ms. 2020.08.27 13:16:32.477 Test6 GBPCAD.rann,M1: Alert: Time[Test6.mq4 15: OrdersHistoryTotal()] = 1 ms. 2020.08.27 13:16:29.096 Test6 GBPCAD.rann,H1: Alert: Time[Test6.mq4 26: SymbolInfoDouble(Symb,SYMBOL_POINT)] = 1 ms. 2020.08.27 13:16:14.593 Test6 GBPCAD.rann,H1: Alert: Time[Test6.mq4 15: OrdersHistoryTotal()] = 23 ms. 2020.08.27 13:14:55.398 Test6 GBPCAD.rann,H1: Alert: Time[Test6.mq4 27: SymbolInfoInteger(Symb,SYMBOL_DIGITS)] = 1 ms. 2020.08.27 13:13:34.891 Test6 GBPCAD.rann,M1: Alert: Time[Test6.mq4 25: SymbolInfoDouble(Symb,SYMBOL_TRADE_TICK_VALUE)] = 2 ms. 36ミリ秒のTimeLocal。ティックボリュームが 大きいシンボルを選択する。 fxsaber 2020.08.27 10:31 #154 ご興味のある方に、再生の方法をご紹介します。 触られないと思ってる人。 2020.08.27 13:17:56.139 Test6 (EURUSD,H1) Alert: Time[Test6.mq5 48: OrdersTotal()] = 2 ms. 2020.08.27 13:17:56.167 Test6 (EURUSD,M1) Alert: Time[Test6.mq5 48: OrdersTotal()] = 39 ms. 2020.08.27 13:17:56.198 Test6 (EURUSD,H1) Alert: Time[Test6.mq5 48: OrdersTotal()] = 54 ms. 2020.08.27 13:18:11.512 Test6 (EURUSD,M1) Alert: Time[Test6.mq5 48: OrdersTotal()] = 3 ms. fxsaber 2020.08.27 10:33 #155 fxsaber:ティックボリュームが 大きいシンボルを選びました。 確認する気もない。最も人気のあるFORTSのシンボルをティック購読でイメージしてください。OnBookEventのOnTickロジックの代わりに。ラグがひどいんでしょうね。 遅延を最小限にするためにどうしたらいいか、公式なアドバイスが欲しい。 Anton 2020.08.27 12:20 #156 fxsaber:ブレーキを再現するには、ONEキャラクターでスクリプトを複数回実行し、同時にOnTickが呼ばれるようにする必要があります。そして、ティックごとにアラートがPINGされます。CPU負荷のグラフでは、terminal64.exeが8つの論理コアのうち最大30%に負荷をかけていることがわかります。スクリプトを実行したEURUSDのチャートは4つだけです。各チャートが一度にどれだけ読み込まれているかがよくわかります。多くの資源はどこへ行くのか? この問いに答えるのは簡単です。 ここでは、多くのデータをコピーします。 HistorySelect(MathRand(), INT_MAX); 実際には、後で使用するために、ターミナルのデータベースから利用可能なすべての取引履歴をEA環境に取り込むコマンドを与えているのです。同一リクエストのキャッシュアルゴリズムの可能性を意図的に潰しているのですね。 しかし、このデータをすべて使うわけではなく、すぐに次の行でリセットしてしまうのです。 _B2(HistorySelect(Tick.time, INT_MAX)); ここでの端末ベースは、明らかに、同期されたアクセスを持つ共有リソースです。そして、その中で意図的に何千ものオーダーやディールを作っているのですね。 このような無意味な動作が、一度に複数のスレッドから1ティック ごとに10回繰り返されるのです。そして、これらの動作を複数のスレッドから同時に行わせることを意図的に行っているのです。 つまり、何をどうしているのか、どこにリソースが使われているのかをよくご存じの上で、同時に「遅延はMT5側の過剰なCPU負荷が原因だ」と主張されているのですね。 とはいえ、明らかにパソコンに問題がありますね。つまり、確かにかなりの量のメモリを積極的に移動させていますが、特にHistorySelect()に一切関係のない関数の実行時間に影響を与えることはないはずです。 b2582のテストでは、1文字チャートに1000回/tick、5つのEA、つまりデフォルトの条件より一桁多い条件でも、Alertは1つも観測されませんでした。 テストシステム:Windows 10 ビルド 18363、Intel Xeon E5-2630 v4 @ 2.20GHz Dmi3 2020.08.27 12:49 #157 Anton:この問いに答えるのは簡単です。ここで多くのデータをコピーします。端末のデータベースから、利用可能なすべての取引履歴をEA環境に取り込み、後で利用するためのコマンドを実際に与えているのです。意図的にランダムに、同一のリクエストの可能なキャッシュアルゴリズムを混乱させようとする。しかし、このデータをすべて使うわけではなく、すぐに次の行でリセットしてしまうのです。ここでの端末ベースは、明らかに、同期されたアクセスを持つ共有リソースです。そして、その中で意図的に何千ものオーダーやディールを作っているのですね。このような無意味な動作が、一度に複数のスレッドから1ティック ごとに10回繰り返されるのです。そして、これらの動作を複数のスレッドから同時に行わせることを意図的に行っているのです。つまり、何をどうしているのか、どこにリソースが使われているのかをよくご存じの上で、同時に「遅延はMT5側の過剰なCPU負荷が原因だ」と主張されているのですね。とはいえ、明らかにパソコンに問題がありますね。つまり、確かにかなりの量のメモリを積極的に移動させていますが、特にHistorySelect()に一切関係のない関数の実行時間に影響を与えることはないはずです。b2582のテストでは、1文字チャートに1000回/tick、5つのEA、つまりデフォルトの条件より一桁多い 条件でも、Alertは1つも観測されませんでした。テストシステム:Windows 10 ビルド 18363、Intel Xeon E5-2630 v4 @ 2.20GHz 同僚 そろそろ航空機のモデリングサークルから出てきてください。 戦況はこうだ。4つのターミナル、約300のExpert Advisor、約30のインストゥルメント。その3分の1がタンブラーに加入している。全てはFORTSのために。そのような条件下でシミュレーションを行う。 Anton 2020.08.27 14:22 #158 Dmi3:同僚そろそろ航空機のモデリングサークルから脱却してください。以下、戦闘状況です。4端末、約300のEA、約30のインストゥルメント。EAの3分の1がタンブラーに加入している。全てはFORTSのために。そのような条件下でシミュレーションを行う。 "Here you go "は、ZIPファイルに加え、問題の詳細な説明文として受け付けます。そうでなければ、空疎な会話になってしまいます。 ここで議論されているのは、提出されたEAのコードとその実行の有効性である。特定された問題点に基づき、端末コードの最適化 作業が行われました。 Dmi3 2020.08.27 16:43 #159 Anton:"Here you go "は、ZIPファイルに加え、問題の詳細な説明文として受け付けます。そうでなければ、空疎な会話になってしまいます。この場合、Expert Advisorから提出されたコードとその実行効率について議論されます。端末のコードは、特定された問題に対して最適化 されています。 特に問題はない、送るものはない。 fxsaberには問題がある。 彼はすでにここで16ページを書いている。 そしてミカエルは2014年から同じ 悩みを抱えていて、すでに149ページ書いています。https://www.mql5.com/ru/forum/38456/page149。 二人とも十分な資格を持っているので、必要な情報はすべて教えてくれます。 ФОРТС. Вопросы по исполнению 2020.08.20www.mql5.com С большими проблемами удалось это сделать (начальник отдела по работе с профессиональными клиентами ДЦ Открытие Евгений Сергеевич,. fxsaber 2020.08.27 19:59 #160 Anton:この問いに答えるのは簡単です。ここで多くのデータをコピーします。端末のデータベースから利用可能なすべての取引履歴をEA環境に取り込み、後で利用するためのコマンドを実際に与えているのです。意図的にランダム化することで、同一のリクエストのキャッシュアルゴリズムを乱す可能性があります。 このスレッドの展開の時系列を追っていないから、発言に言いがかりをつけることを許してしまうのです。 MathRandの行を削除しました。以下、簡単なログです。 2020.08.27 22:38:57.920 Alert: Time[Test6.mq5 40: SymbolInfoDouble(Symb,SYMBOL_TRADE_TICK_VALUE)] = 3 ms. 2020.08.27 22:38:57.923 Alert: Time[Test6.mq5 19: CopyTicksRange(Symb,Ticks,COPY_TICKS_ALL,Tick.time_msc)] = 1 ms. 2020.08.27 22:38:57.926 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 3 ms. 2020.08.27 22:38:57.928 Alert: Time[Test6.mq5 61: AccountInfoDouble(ACCOUNT_EQUITY)] = 1 ms. 2020.08.27 22:38:57.940 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 11 ms. 2020.08.27 22:39:02.227 Alert: Time[Test6.mq5 17: CopyTicks(Symb,Ticks,COPY_TICKS_ALL,0,1)] = 1 ms. 2020.08.27 22:39:02.229 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 2 ms. 2020.08.27 22:39:02.238 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 7 ms. 2020.08.27 22:39:02.241 Alert: Time[Test6.mq5 28: HistoryDealSelect(0)] = 1 ms. 2020.08.27 22:40:34.575 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 2 ms. 2020.08.27 22:40:44.407 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 1 ms. 2020.08.27 22:40:44.409 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 9 ms. 2020.08.27 22:40:46.819 Alert: Time[Test6.mq5 40: SymbolInfoDouble(Symb,SYMBOL_TRADE_TICK_VALUE)] = 1 ms. 2020.08.27 22:40:52.760 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 3 ms. 2020.08.27 22:40:52.764 Alert: Time[Test6.mq5 28: HistoryDealSelect(0)] = 3 ms. 2020.08.27 22:40:54.907 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 3 ms. 2020.08.27 22:41:11.415 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 5 ms. 2020.08.27 22:41:13.517 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 1 ms. 2020.08.27 22:41:14.689 Alert: Time[Test6.mq5 18: CopyTicks(Symb,Ticks,COPY_TICKS_ALL,Tick.time_msc)] = 1 ms. 2020.08.27 22:41:45.343 Alert: Time[Test6.mq5 19: CopyTicksRange(Symb,Ticks,COPY_TICKS_ALL,Tick.time_msc)] = 1 ms. 2020.08.27 22:42:12.156 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 3 ms. 2020.08.27 22:42:19.654 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 2 ms. 2020.08.27 22:42:32.581 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 2 ms. 2020.08.27 22:42:48.662 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 1 ms. 2020.08.27 22:42:49.754 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 2 ms. 2020.08.27 22:42:49.756 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 2 ms. 2020.08.27 22:42:50.803 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 1 ms. 2020.08.27 22:42:50.804 Alert: Time[Test6.mq5 32: HistoryOrderGetInteger(0,ORDER_MAGIC)] = 1 ms. 2020.08.27 22:42:50.805 Alert: Time[Test6.mq5 44: TimeCurrent()] = 1 ms. 2020.08.27 22:43:42.143 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 6 ms. 2020.08.27 22:43:42.148 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 4 ms. 2020.08.27 22:43:54.985 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 2 ms. 2020.08.27 22:44:01.402 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 1 ms. 2020.08.27 22:44:01.405 Alert: Time[Test6.mq5 22: HistorySelect(Tick.time,INT_MAX)] = 2 ms. でも、そのデータを全部使わず、すぐ次の行で捨ててしまうんですね。 ここでいう端末ベースとは、明らかに同期されたアクセスを持つ共有リソースのことである。そして、その中で意図的に何千ものオーダーやディールを作っているのですね。 10K以上の注文が当たり前の実際の口座でテストしています。これらの注文の70%以上が約定しているため、偽注文ではありません。 ちなみにスクリーンショットでは、9331+576 !=12529となっています。 このような無意味な動作が、複数のスレッドから同時に1ティック ごとに10回繰り返されるのです。そして、複数のスレッドからのこれらのアクションを意図的に同時に発生させているのです。 違うキャラクターで困っています。より早く問題を再現するために、1つの記号を提案します。 1回の刻みで10回繰り返すことが、必要不可欠なのです。1つのEAに専攻の違うTCが何十個も入っているのが普通ですから。 つまり、何をどうしているのか、リソースがどこに行っているのかをよくご存知の上で、「遅延はMT5側のCPUの過剰な負荷によるものだ」と主張されているのですね。 とはいえ、明らかにパソコンに問題がありますね。つまり、確かにかなりの量のメモリを積極的に動かしていますが、特にHistorySelect()に一切関係のない関数の実行時間には影響を与えないようにする必要があります。 あなたの無能さを非難することはできませんが、あなたの書いたものは、控えめに言って、困惑を引き起こします。HistorySelectは、4つのインデックス(注文のテーブルの始まり/終わり、取引のテーブルの始まり/終わり)を見つけることです。テーブルは時間順にソートされているので、最悪でも2値検索がある(はず)。10K注文の場合は瞬時です(両対数を計算してください)。メモリ容量の動きとは!ここでは誰も恐ろしいHistorySelectByPositionについて話していない。初級HistorySelectが影響します。 b2582のテストでは、1文字チャートに1000回/tick、5つのEA、つまりデフォルトの条件より一桁多い条件でも、Alertは1つも観測されませんでした。 テストシステム:Windows 10 ビルド 18363、Intel Xeon E5-2630 v4 @ 2.20GHz テストを実施した取引口座のログイン情報をこちらにご記入ください。 1...91011121314151617181920212223...94 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
同じスクリプトを他の取引プラットフォームで比較するのも面白いかもしれませんね。
MT4 b1280です。
スリップは3回だけで、その後はほとんど飛び出すことはありませんでした。おそらくHistorySelectと CopyTicksがないのでブレーキを作るのは難しいでしょう。
どちらもHaswellなので、xeonは動作周波数がかなり低く、パフォーマンスやシングルテストでは性能劣化が ありますが、マルチスレッドでの最適化だけは有利になります。最新機種のi3は、動作がかなり速くなるはずです
キャッシュレベルの速度への影響や、Zen2や最新のIntelの速度については、開発者に聞いてみてください。
つける
私が持っているRyzen 3700xは、Intelでテストをすることができます。
例えば、次のMQL5Scriptsのようなスクリプトを使用します。
タイマーで何度もループさせる
ここではテストの話ではなく、注文 実行の遅れの話をしています。この遅延があるから、浮いているんです。そして、TSも私もかなり悩まされます。
3つだけ出てきて、その後はほとんど出てきません。HistorySelectやCopyTicksがないので、ブレーキを作るのが大変なのでは?
MT4でも待ってました。
36ミリ秒のTimeLocal。ティックボリュームが 大きいシンボルを選択する。
ご興味のある方に、再生の方法をご紹介します。
触られないと思ってる人。
ティックボリュームが 大きいシンボルを選びました。
確認する気もない。最も人気のあるFORTSのシンボルをティック購読でイメージしてください。OnBookEventのOnTickロジックの代わりに。ラグがひどいんでしょうね。
遅延を最小限にするためにどうしたらいいか、公式なアドバイスが欲しい。
ブレーキを再現するには、ONEキャラクターでスクリプトを複数回実行し、同時にOnTickが呼ばれるようにする必要があります。そして、ティックごとにアラートがPINGされます。
CPU負荷のグラフでは、terminal64.exeが8つの論理コアのうち最大30%に負荷をかけていることがわかります。スクリプトを実行したEURUSDのチャートは4つだけです。各チャートが一度にどれだけ読み込まれているかがよくわかります。
多くの資源はどこへ行くのか?
この問いに答えるのは簡単です。
ここでは、多くのデータをコピーします。
実際には、後で使用するために、ターミナルのデータベースから利用可能なすべての取引履歴をEA環境に取り込むコマンドを与えているのです。同一リクエストのキャッシュアルゴリズムの可能性を意図的に潰しているのですね。
しかし、このデータをすべて使うわけではなく、すぐに次の行でリセットしてしまうのです。
ここでの端末ベースは、明らかに、同期されたアクセスを持つ共有リソースです。そして、その中で意図的に何千ものオーダーやディールを作っているのですね。
このような無意味な動作が、一度に複数のスレッドから1ティック ごとに10回繰り返されるのです。そして、これらの動作を複数のスレッドから同時に行わせることを意図的に行っているのです。
つまり、何をどうしているのか、どこにリソースが使われているのかをよくご存じの上で、同時に「遅延はMT5側の過剰なCPU負荷が原因だ」と主張されているのですね。
とはいえ、明らかにパソコンに問題がありますね。つまり、確かにかなりの量のメモリを積極的に移動させていますが、特にHistorySelect()に一切関係のない関数の実行時間に影響を与えることはないはずです。
b2582のテストでは、1文字チャートに1000回/tick、5つのEA、つまりデフォルトの条件より一桁多い条件でも、Alertは1つも観測されませんでした。
テストシステム:Windows 10 ビルド 18363、Intel Xeon E5-2630 v4 @ 2.20GHz
この問いに答えるのは簡単です。
ここで多くのデータをコピーします。
端末のデータベースから、利用可能なすべての取引履歴をEA環境に取り込み、後で利用するためのコマンドを実際に与えているのです。意図的にランダムに、同一のリクエストの可能なキャッシュアルゴリズムを混乱させようとする。
しかし、このデータをすべて使うわけではなく、すぐに次の行でリセットしてしまうのです。
ここでの端末ベースは、明らかに、同期されたアクセスを持つ共有リソースです。そして、その中で意図的に何千ものオーダーやディールを作っているのですね。
このような無意味な動作が、一度に複数のスレッドから1ティック ごとに10回繰り返されるのです。そして、これらの動作を複数のスレッドから同時に行わせることを意図的に行っているのです。
つまり、何をどうしているのか、どこにリソースが使われているのかをよくご存じの上で、同時に「遅延はMT5側の過剰なCPU負荷が原因だ」と主張されているのですね。
とはいえ、明らかにパソコンに問題がありますね。つまり、確かにかなりの量のメモリを積極的に移動させていますが、特にHistorySelect()に一切関係のない関数の実行時間に影響を与えることはないはずです。
b2582のテストでは、1文字チャートに1000回/tick、5つのEA、つまりデフォルトの条件より一桁多い 条件でも、Alertは1つも観測されませんでした。
テストシステム:Windows 10 ビルド 18363、Intel Xeon E5-2630 v4 @ 2.20GHz
同僚
そろそろ航空機のモデリングサークルから出てきてください。
戦況はこうだ。4つのターミナル、約300のExpert Advisor、約30のインストゥルメント。その3分の1がタンブラーに加入している。全てはFORTSのために。そのような条件下でシミュレーションを行う。
同僚
そろそろ航空機のモデリングサークルから脱却してください。
以下、戦闘状況です。4端末、約300のEA、約30のインストゥルメント。EAの3分の1がタンブラーに加入している。全てはFORTSのために。そのような条件下でシミュレーションを行う。
"Here you go "は、ZIPファイルに加え、問題の詳細な説明文として受け付けます。そうでなければ、空疎な会話になってしまいます。
ここで議論されているのは、提出されたEAのコードとその実行の有効性である。特定された問題点に基づき、端末コードの最適化 作業が行われました。
"Here you go "は、ZIPファイルに加え、問題の詳細な説明文として受け付けます。そうでなければ、空疎な会話になってしまいます。
この場合、Expert Advisorから提出されたコードとその実行効率について議論されます。端末のコードは、特定された問題に対して最適化 されています。
特に問題はない、送るものはない。
fxsaberには問題がある。 彼はすでにここで16ページを書いている。
そしてミカエルは2014年から同じ 悩みを抱えていて、すでに149ページ書いています。https://www.mql5.com/ru/forum/38456/page149。
二人とも十分な資格を持っているので、必要な情報はすべて教えてくれます。
この問いに答えるのは簡単です。
ここで多くのデータをコピーします。
端末のデータベースから利用可能なすべての取引履歴をEA環境に取り込み、後で利用するためのコマンドを実際に与えているのです。意図的にランダム化することで、同一のリクエストのキャッシュアルゴリズムを乱す可能性があります。
このスレッドの展開の時系列を追っていないから、発言に言いがかりをつけることを許してしまうのです。
MathRandの行を削除しました。以下、簡単なログです。
でも、そのデータを全部使わず、すぐ次の行で捨ててしまうんですね。
ここでいう端末ベースとは、明らかに同期されたアクセスを持つ共有リソースのことである。そして、その中で意図的に何千ものオーダーやディールを作っているのですね。
10K以上の注文が当たり前の実際の口座でテストしています。これらの注文の70%以上が約定しているため、偽注文ではありません。
ちなみにスクリーンショットでは、9331+576 !=12529となっています。
このような無意味な動作が、複数のスレッドから同時に1ティック ごとに10回繰り返されるのです。そして、複数のスレッドからのこれらのアクションを意図的に同時に発生させているのです。
違うキャラクターで困っています。より早く問題を再現するために、1つの記号を提案します。
1回の刻みで10回繰り返すことが、必要不可欠なのです。1つのEAに専攻の違うTCが何十個も入っているのが普通ですから。
つまり、何をどうしているのか、リソースがどこに行っているのかをよくご存知の上で、「遅延はMT5側のCPUの過剰な負荷によるものだ」と主張されているのですね。
とはいえ、明らかにパソコンに問題がありますね。つまり、確かにかなりの量のメモリを積極的に動かしていますが、特にHistorySelect()に一切関係のない関数の実行時間には影響を与えないようにする必要があります。
あなたの無能さを非難することはできませんが、あなたの書いたものは、控えめに言って、困惑を引き起こします。HistorySelectは、4つのインデックス(注文のテーブルの始まり/終わり、取引のテーブルの始まり/終わり)を見つけることです。テーブルは時間順にソートされているので、最悪でも2値検索がある(はず)。10K注文の場合は瞬時です(両対数を計算してください)。メモリ容量の動きとは!ここでは誰も恐ろしいHistorySelectByPositionについて話していない。初級HistorySelectが影響します。
b2582のテストでは、1文字チャートに1000回/tick、5つのEA、つまりデフォルトの条件より一桁多い条件でも、Alertは1つも観測されませんでした。
テストシステム:Windows 10 ビルド 18363、Intel Xeon E5-2630 v4 @ 2.20GHz
テストを実施した取引口座のログイン情報をこちらにご記入ください。