Конечной целью трейдера является извлечение прибыли посредством торговых операций на финансовых рынках. В этой статье дается описание терминов и процессов торговой платформы MetaTarder 5, знание которых необходимо для правильного понимания работы торговых функций языка MQL5. Ордера — это принятые торговым сервером запросы на совершение торговых...
このMQの壁は、フォーラムのメンバーのサポートなしには乗り切れないと感じています。コードは短いので、プロでもすぐに分かるはずです。そこに欠点はない。マーケットウォッチよりも、ポジションを通した価格の方が、はるかに速く取得できることがよくわかります。どうしてMQは当たり前のことがわからないのだろう--。
1.あなたのテストは、条件により、本当に微小な割合の反復をカウントしています。
要するに、99%以上の反復処理が1マイクロ秒以下で行われるため、プロセッサがタスクで過負荷になり、与えられたタスクの実行を遠くの棚に追いやった異常だけをカウントしているのです。
また、条件＞0とした場合でも、客観性はない。
2.このような高速演算の時間測定は、1回の反復ではなく、全サイクルの時間としてのみ行うべきである。
3.しかし、あなたの例では周期が10秒に制限されているので（なぜ!ティックについては、0.1秒でも十分だと思います。なぜなら、1秒間に3つのtickが到着し、3つのtickがそれぞれ10秒間、並行して実行されることが十分にあり得るからです）、タイミングは必要ありません。一定時間内に何回反復実行されるかを計算するのが簡単です。多ければ多いほど、生産性が上がる。
あなたのコードを "ちょっと "修正しました。私のバリアントは、より現実を反映していると思います。
2つのバリアントが混ざらないように、計算は1つずつ行われます。偶数番目のティックはSYMBOL_BID 用、奇数番目はGetBid()用です。
念のため、最適化に対してコンパイラを騙す試みとして、和とその出力を追加しました。
出力結果は累積されます。
私の結果です。
ご覧の通り、性能の差は通常版の3倍もあります。
ご覧の通り、性能の差はオリジナル版の3倍にもなっています。fxsaberのオリジナル版はGetBidの優位性を示しているのか、それともより強力な/負荷の少ないPCの話なのか？
fxsaberによるオリジナル版はGetBidの優位性を示すのか、それとももっと強力な/負荷の少ないPCなのでしょうか？
また、彼の亜種は、CPU負荷が最大になったときにGetBidの優位性を示しました。しかし、同時に私のバリエーションは、同じ負荷で通常の機能の3倍のアドバンテージを示しています。
これは、私のバリアントが入札価格取得の全反復の平均時間を考慮し、そのごく一部が異常なハングアップを伴うからです。
どのような理由で、プロセッサが困難な「分」において、通常の機能（遅延が100μ以上ある場合）に埋もれてしまうのか、誰にもわからない。それでも平均時間はレギュラー機能の3倍以上
つまり、例えば（Interval#A > 100）であれば、このようになります。
一方、(Interval#A > 0)の場合は、すでにかなり異なっており、入札価格を得るための通常バージョンと代替バージョンの間の異常な遅延のランダムな分布を示しています。
を、同じCPU負荷でテストしてみたところ、このような結果になりました。
ですから、fxsaberさんのテストのバージョンは、客観性からは程遠いと思います。
エージェントでCPUに負荷をかけるのではなく、このスクリプトで負荷をかけました。より効率的でした。
fxsaberテストに若干の修正を加え、計算に占める反復回数の割合を明確に示した後。
すなわち、約0.01％です。
You bet.
SymbolInfoDouble(_Symbol,SYMBOL_BID)の平均実行時間が50ナノ秒程度であれば、実行時間が100 000ナノ秒以上のものだけを考慮するようにします。
fxsaberテストに若干の修正を加え、計算に占める反復回数の割合を明確に示した後。
すなわち、約0.01％です。
SymbolInfoDouble(_Symbol,SYMBOL_BID)の平均実行時間が約50ナノ秒の場合、100 000ナノ秒以上の反復処理のみをカウントしています。
単純に100μs以上ではなく、3μs以上という条件にすればよかったのです。結果は、どうやら同じだったようだ。セグメント別の調査で、異なる実行条件では、異なるセグメント、異なるセクションで違いがあるかもしれないと考えたのです。実行の優先順位は、何かに依存して作られることが多い。軽い負荷ではいくつかの優先順位、高い負荷では他の優先順位、重要なものでは、コンピュータがハングアップしてクラッシュしないようにするもので、パフォーマンスはバックグラウンドになります。
一般的に、ハードウェアの70％以上の負荷で取引するのはおかしいと言われています。ほぼクリティカルな性能です。戦闘用EAの鉄の負荷は60％以下であることが望ましい。
とか、すでにHFTブローカーがあるのかとか)
シンボルインフォティックのテストは、市場概要に1つのシンボルしかない場合と、数十のシンボルがある場合で、1つのツールに依頼することを試してみてください。
サーバーが圧縮されたトラフィックを送信している可能性が高く、データが解凍されるときに SymbolInfoTick に周期的な遅延が発生している。
すなわち、シンボルの数が多い場合、テスト時間の落ち込みがさらに頻繁になったり、深くなったりします
最近のビルドでは、ティックストリームを受信しても、理論上では何の影響もありません。実用的には、SymbolInfoTickはすでにキャッシュで動作 していますが、一部の市民は黒猫を探し続けています。
テストでは8割もないんですよ。4つのコアで6つのエージェントが動作しており、つまり100%保証されています。
問題は、彼のシステムのタスクスケジューラが、この状況をどのように処理しているかだ。同時に、端末の実装にこそ原因があるとの主張も行っている。
つまり、コンピュータに負荷がかかり、文字通りコンピュータ上のあらゆるものが遅くなる状況を人為的に作り出し、「ああ、ほら、どうして時々端末がラグるんだ」という形で何らかの主張がなされるのである。
そんな状況でも「約0.01％」なのだから、細かいことはいい加減にしろ！と目をつぶることにしよう。病院の平均温度なんて誰も気にしない」「ラグがあると取引時に困る」「HFTが欲しい」というだけで十分です。
さらに、古いオフィスのデスクトップや枯れた仮想マシンで20人のエキスパートにHFTを させることも当然ながら可能です。
PS PositionSelectByTicket()の実装では、確かにアクセス同期のある共有リソースにアクセスすることができます。そして、すべてのコールでポジションを選択しなければ、古い価格を読んでいることになります。SymbolInfoDoubleを介した「スナップショット」の方が簡単だったのです。