MT5とスピードの関係 - ページ 4

新しいコメント
 
機器に依存することは理解している
 
Alexsandr San:
機器に依存することは理解している

そんなことないですよー。

2020.05.29 15:08:44.938 Terminal        Windows 7 Service Pack 1 build 7601, Intel Core i7-6850 K  @ 3.60 GHz, 23 / 31 Gb memory, 43 / 226 Gb disk, IE 11, UAC, Admin, GMT+3
 
Alexsandr San:
ハードにもよるんでしょうけど。

そんなことはないだろう ))))

しかも、忙しいパソコンからでもなく...。

 
prostotrader:

そんなことないですよー。

はい！あなたのマシンと前のマシンの結果が違うので、電源の手段ではなく、私が間違っています。

 
Aleksey Mavrin:

onMainとは何ですか？ 各イベントがonMainを呼び出してキューを処理する場合、onMainのキューに複数のイベントが存在するのはなぜですか？

OnMainは関数です。実際のコードではなく、特殊なケース、つまり「OnMain関数実行中に現在の実キューの 状態を知る方法は ない」という主張に対する回答です。計算そのものに対するアプローチが 違うのです

 
A100:

OnMainは関数です。実際のコードではなく、特殊なケース、つまり「OnMain関数実行中に現在の実キューの 状態を知る方法は ない」という主張に対する答えです。 これは、計算そのものに対するアプローチとは異なる ものです。

そこで、念のため、OnMain...

:);)
 
fxsaber:


Combat Advisorsでは、_B(FuncName(...), AlertTime) まで怪しいところで関数をラップしてしまっているのです。ここでは、最新のエントリーからログの一部を抜粋してご紹介します。

時間欄は、フリーズの発生頻度を示しています。

概念を置き換えているのです。

以下は、あなたのオリジナルの文章です。

残念ながら、このようなHistorySelectの呼び出しは5-30ミリ秒 続きます（Release-EX5で自分で計測）。Expert Advisor が OnTick でこのような更新を何度も行う場合（良い意味で、任意の一時停止後に行うべき）、その更新を行う。例えば、OrderSend.のたびに、すべてが非常識なほど高価で長くなる。HistorySelectは、1回のOnTickで数秒まで加算することができます。

あなたの端末でも、1コールあたりの平均時間が0.2msと、元の文で指定した値よりも測定可能なほど短くなっています。

今、ある関数の実行時間が平均より明らかに長くなることがあるとおっしゃいましたね。これは別の質問です。

HistorySelect() リクエストはすべて、シンクロナイザーのもとでの端末ベースへの本格的な呼び出しとなる。これはやむを得ないことです。はい、アクセス同期の存在を考慮すると、この関数の実行時間が非常に短いことは保証できません。

HistoryDealsSelect()関数とHistoryOrdersSelect()関数を追加することで提案する解決策は、この意味において全く何も変わりません。

最大時間、平均時間を確認するためのスクリプトです。

void OnStart()
  {
   MqlTick Tick;
   SymbolInfoTick(_Symbol, Tick);
//---
   ulong start,end,max_time=0,avr_time=0;
   int   count=100000;
   for(int i=0; i<count; i++)
     {
      start=GetMicrosecondCount();
      HistorySelect(Tick.time, INT_MAX);
      end=GetMicrosecondCount()-start;
      //--- >1 ms
      if(end>1000)
         Print(" > 1 ms for one HistorySelect: ",DoubleToString(end/1000.0,2)," ms");
      //---
      if(end>max_time)
         max_time=end;
      avr_time+=end;
     }
   Print("Last tick time. Selected orders: ",HistoryOrdersTotal(),"; max time: ",DoubleToString(max_time/1000.0,3)," ms; avr time: ",DoubleToString(avr_time/1000.0/count,3)," ms; ",count," iterations");
//---
   Tick.time=(Tick.time/86400)*86400;
   max_time=0;
   for(int i=0; i<count; i++)
     {
      start=GetMicrosecondCount();
      HistorySelect(Tick.time, INT_MAX);
      end=GetMicrosecondCount()-start;
      //--- >1 ms
      if(end>1000)
         Print(" > 1 ms for one last day HistorySelect: ",DoubleToString(end/1000.0,2)," ms");
      //---
      if(end>max_time)
         max_time=end;
      avr_time+=end;
     }
   Print("Last day. Selected orders: ",HistoryOrdersTotal(),"; max time: ",DoubleToString(max_time/1000.0,3)," ms; avr time: ",DoubleToString(avr_time/1000.0/count,3)," ms; ",count," iterations");
//---
   HistorySelect(0, INT_MAX);
   Print("Orders total: ",HistoryOrdersTotal());
  }
2020.05.29 17:22:04.195 TestHistorySelect (EURJPY,H1)   Last tick time. Selected orders: 0; max time: 0.034 ms; avr time: 0.001 ms; 100000 iterations
2020.05.29 17:22:06.771 TestHistorySelect (EURJPY,H1)   Last day. Selected orders: 141; max time: 0.101 ms; avr time: 0.027 ms; 100000 iterations
2020.05.29 17:22:08.039 TestHistorySelect (EURJPY,H1)   Orders total: 31448
 
Anton:

最大時間と平均時間を確認するスクリプトです。

引用前の意見にはコメントしません。以下は、あなたのスクリプトを実行した結果です。

正確には、終了を待ちきれなかったので、反復回数を100Kから1Kに変更したのです。

        Last tick time. Selected orders: 0; max time: 3.880 ms; avr time: 1.315 ms; 1000 iterations
        Last day. Selected orders: 2061; max time: 7.131 ms; avr time: 4.309 ms; 1000 iterations
        Orders total: 50113

これでは、満足な評価を得ることすらできないのではないか？

その不条理さに目を向けてください。愚直に案件数を調べるためには、HistorySelectを呼び出す 必要があるのです!これは、大げさに言えば、合理的ではありません。


HistorySelectがあるからこそ、1tickにせいぜい数十ミリ秒を費やしているのです。

 
A100:

最もシンプルな形で。

計算のやり方そのものを変えればいいのです（タスクに必要な回数だけ中間戻りをする）。しかし、もしそれが複雑なら、最初の段階でOnMainはあなたにとって存在しないと考えてください（あなたはメインコードをOnMainではなく、OnTrade2XXに置く）、したがって、OnMainで何かを学ぶ必要はありません。

ありがとうございます。まさに最初からそのように理解していたので、「理解しきれていない」と言ったのです。ここでは、簡単なシナリオの例を紹介します。


OrderSendを行うのです。OrderSendの後、あるポジションがマークでクローズしていなければ、再度OrderSendを行う。 これは全てプログラム化されたロジックである。Asyncは使用しない。


さて、私たちのロボットに起こった状況です。OrderSendを送信し、それが実行されている間にLimiterが作動し、上記のポジションのTPが実行されました。


ロボットの実装を模式的に教えてください。HistorySelectやOnTradeTransaction-spyの ような、コードのどの場所でも取引の全履歴にアクセスできるような、ブレーキなしの実装方法がわからない。イベントキューにアクセスする仕組みが実装されていれば、上記の例は初歩的な解決になります。


開発者を含め、MT5に強い皆さん、この（ 上記太字の 2行）単純でない（複雑と言うのも怖い）売買ロジックの実装方法を教えてください。

 
A100:

OnMainは関数です。これは実際のコードではなく、特殊なケースです。「 OnMain関数実行中に 現在の実キューの 状態を知る方法はない」という主張に対する答え です。 これは、計算そのものに対する別のアプローチ です。

まあ、そうなんでしょうね。と、男たちは話していた。これを実装するためには、MQLプログラムの実行構造を、a) 少なくとも2スレッドに変更するか、b) キュー処理にアクセスし管理する仕組みを追加する必要があります。

現在の構造では、あなたの提案するスキームを実現することは不可能です。

1234567891011...94
新しいコメント