ストラテジーテスターにおける最適化 - ページ 16

 
Renat:

最新のビルドでは、タスク実行時のシステムオーバーヘッドを完全に排除し、約2000ミリ秒からゼロに削減しました。

jooさんからご提案いただいた、計算タスクの実行結果です。

設定(チャート履歴を使用しないため、あえて日付が設定されています)。

実行するパラメータ。

使用代理店(現地代理店4社)。

最適化結果。

最適化にはわずか25秒しかかからず、18,432回のパスが行われた。

昔の 取引戦略テスターの最適化タスクに 立ち返る。

425ビルドのための総合計画の改善がもたらしたもの。

  • 合格に向けたシステムオーバーヘッドの削減
  • シミュレーションの種類に "数学計算 "モードを追加し、セットアップを簡素化しました。

再び同じハードウェア(4ローカルエージェント)で、425ビルドのクリーンキャッシュを使用します。

Tester	optimization passed in 0 minutes 07 seconds
Tester	genetic optimization finished on pass 19456 (of 100000020000001)
Tester	result cache was used 10124 times
Tester	genetics is over

当初の問題提起(1パスあたり2秒のオーバーヘッド)と比較し、問題解決に成功しました。同じタスクでも、25秒ではなく7秒でカウントが始まりました。

システムオーバーヘッドとの戦いの基本は、タスクのバッチ処理にあった。ここで、各エージェントの実行速度を測定し、1〜64個のタスクのバッチを与えて計算させました。その結果、テストの準備や結果を得るために必要な時間も比例して短縮されます。高速エージェントは、低速エージェントよりも多くのタスクと大きなバッチサイズを取得します。特に高速な計算を行う場合、テストの準備や結果の転送にかかる時間と同等の時間で有用な計算を行うことができるため、非常に有効です。

エージェントのメンテナンスを最適化するための作業はまだ完了していません。MQL5クラウドネットワークでリモートエージェントが効率的に作業するためには、通信コストの削減が大きな課題です。

 

理解するのに役立つ!

以下のコードブロックは、デモ口座のターミナルでは問題なく動作しますが、テストするとエラーメッセージ4109が 表示されます。

if(!ChartGetDouble(0,CHART_PRICE_MAX,0,price_max))
 {
  printf(__FUNCTION__,": Не получены данные по максимальной цене. Ошибка: %g.",GetLastError());
 }

と同じ状況が起こります。

if(!ChartGetDouble(0,CHART_PRICE_MIN,0,price_min))
 {
  printf(__FUNCTION__,": Не получены данные по минимальной цене. Ошибка: %g.",GetLastError());
 }
 
slyusar:

理解するのに役立つ!

以下のコードブロックは、デモ口座のターミナルでは問題なく動作しますが、テストするとエラーメッセージ4109が 表示されます。

と同じ状況が起こります。

チャートとグラフィカルなオブジェクトは、テスト速度を劇的に低下させるため、テスト中にモデル化されません。
 
Renat:
チャートとグラフィカルなオブジェクトは、テスト中にモデリングされないため、テスト速度が極端に低下します。
なるほど、ありがとうございます。この状況を打開する方法はないのでしょうか。
 
Renat:
チャートとグラフィカルなオブジェクトは、テスト中にモデリングされないため、テスト速度が極端に低下します。
このようなグラフィックのないシミュレーションは、「ビジュアライゼーション」のないモードだけにしてほしいと切に願います。
 
sergeev:
このようなグラフィックのないモデリングは、「ビジュアライゼーション」のないモードだけにしてほしいと切に願っています。
完全対応、グラフィックは時に非常に必要...
 
Renat:

トレーディング・ストラテジー・テスターの最適化という昔の作業に 戻る。

425ビルドの全体プランの改善は、結果として

  • 合格に向けたシステムオーバーヘッドの削減
  • シミュレーションの種類を選択する際に、明示的に「数学計算」モードを追加し、セットアップを簡素化した

同じハードウェア(4ローカルエージェント)、425ビルドでキャッシュをクリーンにした場合の別の結果です。

当初の問題提起(1パスあたり2秒のオーバーヘッド)と比較し、問題解決に成功しました。同じタスクでも、25秒ではなく7秒でカウントが始まりました。

システムオーバーヘッドとの戦いの基本は、タスクのバッチ処理にあった。ここで各エージェントの実行速度を測定し、1〜64個のタスクのバッチを与えて計算させました。その結果、テストの準備や結果を得るために必要な時間も比例して短縮されます。高速エージェントは、低速エージェントよりも多くのタスクと大きなバッチサイズを取得します。特に、有用な計算を行う時間がテスト準備や結果送信の時間に匹敵するような高速計算タスクでは、その効果は絶大です。

エージェントのメンテナンスを最適化するための作業はまだ完了していません。MQL5クラウドネットワークでリモートエージェントが効率的に作業するためには、通信コストの削減が大きな課題です。

より良い方向への非常に重大な変化 - ありがとうございます。

64個のパラメータという制限はどうでしょうか?少なくとも私にとっては、オプティマイザーの本格的な使用を抑制する唯一の要因です。私はすでに、どんな大騒ぎも忘れて、「現実」の世界のために書きたいのです。そうすれば、テスターはコードを変更することなく最適化できるはずです。

 
テストビジュアライザーを実行した後に、パラメータを扱います。
 
joo:

改善のための非常に重大な変化 - ありがとうございます。

64パラメータの制限はどうなっていますか?少なくとも私にとっては、オプティマイザーを本格的に使うことを抑制する唯一の要因です。そして、そのような騒ぎを忘れて、「本当の」コードを一度に書き、コードを変更せずにテスターで最適化できるようにしたい、と思っています。

応援しています。
レナート
パラメータについては、テストビジュアライザーの起動後に扱います。
ありがとうございます! お待ちしております。
 
Renat:

トレーディング・ストラテジー・テスターの最適化という古い 問題に立ち戻る。

同じハードウェア(4ローカルエージェント)、425ビルドでキャッシュをクリーンにした場合の次の結果。

当初の問題提起(1パスあたり2秒のオーバーヘッド)と比較すると、問題解決に成功したことになります。同じ問題が25秒から7秒になりました。

次にリリースされるビルドでは、数学的問題の質量計算を最適化するために多くの作業を行いました。システムオーバーヘッドをゼロにした。

現在、同じハードウェア(Intel Q9400、4ローカルコア)において、同じタスクで〜18000回の計算を行うと1秒かかります(前回は7秒、以前は25秒かかりました)。

2011.04.04 20:12:34    Tester    optimization passed in 0 minutes 01 seconds
2011.04.04 20:12:34    Tester    genetic optimization finished on pass 18432 (of 1000000002000000001)
2011.04.04 20:12:34    Tester    result cache was used 9718 times
2011.04.04 20:12:34    Tester    genetics is over


比較のために、同じハードウェアで同じ数学的タスクが400万回のパスを計算するのにかかる時間を示します(ステップを0.005に減らすと、計算の総数が400万回になり、フル計算を実行できるようになります)。



2011.04.04 20:10:34    Tester    optimization passed in 0 minutes 46 seconds
2011.04.04 20:10:34    Tester    optimization finished, total passes 4004001


46秒の間に400万件のタスクの完全な誤算が起こり、最適化結果ウィンドウには400万行すべての結果が表示され、テーブル全体は瞬時に任意のフィールドでソートされ、最適化グラフは400万件すべての値を小気味よく描画し、3Dグラフは同じ結果から3D表面を描き、異なる角度で回転させています。