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

新しいコメント
 

HistorySelectは、選択した履歴の物理的なスナップショットをEAのローカルキャッシュに作成するため、安心して履歴を確認することができることに注意してください。これをしないと、アカウントの履歴が非同期で更新/同期されるため、非常に不愉快な影響が出る可能性があります。もちろん、ユーザー自身がインターフェースから手動で履歴の深さを変更できることは言うまでもありません。

それゆえ、このようなコピーコストが発生するのです。この履歴を意図的に複数のスレッドから同時にキャッシュに強制コピーしようとすれば、なおさらです。

サンプリング操作ですでに多くの最適化を行い、今は最適なキャッシュの更新を考えていますが、実際には99％のサンプルは全く役に立たず、その場でスキップされることになるでしょう。

つまり、サンプリング制限を特にランダム化しない限り、キャッシュは100%に近いヒットを表示することになる。

おそらく来週には、すでに効果的な解決策が見つかっていることでしょう。

 
Renat Fatkhullin:

HistorySelectは、選択した履歴の物理的なスナップショットをEAのローカルキャッシュに作成するため、安心して履歴を確認することができることに注意してください。これをしないと、アカウントの履歴が非同期で更新/同期されるため、非常に不愉快な影響が出る可能性があります。これは、ユーザー自身がインターフェースから手動で履歴の深さを変更できることは言うまでもありません。

注文の表と案件の表があります。HistorySelectを呼び出した時点で4つのインデックスが分かっているのに、なぜ物理的なスナップを行う必要があるのでしょうか？

だから、コピー代が高いんです。特に、複数のスレッドからこの履歴をキャッシュに同時に強制コピーすることを具体的に扱うと、そのようなことが可能になる。

サンプリング動作はすでにかなり最適化されており、今はキャッシュの最適な更新を考えていますが、実際には99％のサンプルは全く役に立たず、その場でスキップされるでしょう。

つまり、サンプリング制限を特にランダム化しない限り、キャッシュは100%に近いヒットを表示することになる。

おそらく来週には、すでに効果的な解決策が見つかっていることでしょう。

HistoryDealSelectとHistoryOrderSelectは、関連するサンプルを破棄するようになりました。MT4のように、インデックスで両方のテーブルにアクセスすることはできないのでしょうか？新機能を導入する。

トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム

バグ、バグ、質問

fxsaber, 2020.08.20 11:28

社内の新機能。 
int OrderExist( const string symbol, ENUM_ORDER_TYPE type, ulong magic, ulong &tickets[] );

int PositionExist( const string symbol, ENUM_POSITION_TYPE type, ulong magic, ulong &tickets[] );

インデックスが求めているのはなぜ、自分の口座の取引数を一箇所で把握しなければならないのか理解できない。

 

そして、これらのテーブルはいつでも変更することができます。その中の個々の記録も同様です。

非同期処理、同期処理、ユーザーが設定した手動での深度モードなどにより、誰もその不変性を保証することはできません。

上に書いたように、インテリジェントなキャッシュ技術を適用することで、Select関数のコストをゼロにすることができるのです。もちろん、サンプリング限界を特別にランダム化すれば別ですが。最終日は変更可能で、常に未来・最終回であればキャッシュを無効にすることはない。最近の取引は控えめにキャッシュに追加されます。


MT4では、キャッシュの作成が非表示になるだけで、同じように動作します。MT4のOnTick/OnStartごとに、ターミナルは各EAの相場環境のスナップショットを自動的かつ惜しげもなく作成します。

そのため、MQL4のコードからデータ準備の真の遅れを評価することはできません。幸いなことに、MT4ではデータは小さくシンプルです。


MT5では、遅延を減らすため、また無駄な作業をしないために、相場環境の自動生成のコストを諦めました。その代わり、ロボット開発者が必要なものを正確に要求できるよう、コストの完全なコントロールを可能にしました。

MT5の市場環境はMT4と比較して巨大であり、単純に再現することができないことに注意してください。

あなたのテストでは、これらの高価なサンプルの一つを利用したのです。

私たちはそれを解決します。それが私たちの利益です。

 
Renat Fatkhullin:

そして、これらのテーブルはいつでも変更することができます。その中の個々の記録も同様です。

非同期処理、同期処理、ユーザーが設定した手動での深度モードなどにより、誰もその不変性を保証することはできません。

すでに最後の取引が行われる前に、別の取引が取引履歴に表示されることがあるということですか？トレードが変わったのなら、別のしかし、すでにあるリストの中に挟み込むというのは......気がつきませんね。

 

OrderExist と PositionExist は、シンボル、取引タイプ、medzhik によるエントリーを検索するために、すべての注文またはポジションをループすることを回避する特別な最適化関数です。

その結果、チケットの配列になります。


これらの機能を利用することで、プログラムが大幅に節約できる可能性があります。特に、オープンポジションやオーダーを一括して呼び出す場合、常にオーバーシュートループを繰り返しています。

今後、膨大な トレードデータにアクセスするための、より効果的な機能を実装していく予定です。

また、言語も飛躍的に強化・簡略化され、より強力な機能を持つようになります。

 
fxsaber:

取引履歴の中に、すでに最後の取引の前に、別の取引がある可能性があるということですか？案件が変更になった場合は、別のしかし、すでにあるリストの中に挟み込むというのは......気がつきませんね。

理屈ではそうなんですけどね。

同期処理も忘れてはいけません。プラットフォームでは膨大な数の処理が非同期で行われます。

例えば、取引所や流動性プロバイダーとゲートウェイを統合すると、数秒から数分の遅延でトランザクションレポートを送信することがあります。多くの場合、APIはリコンサイルのための履歴へのアクセスを全く提供せず、遅くて非リズミカルなレポートジェネレータを提供します。

マーケットオープン時、または予期せぬゲートウェイの再接続により、レポートが遅延することがあります。サーバー上の履歴に複製され、直ちに非同期で端末に送信される。日付でソートされているため、適切な場所に挿入され、その間に新しいトレードを開くことができるのです。

ほとんどの統合APIは、文盲で機能不全に陥っており、保証された ゲートウェイを作ることはほとんど不可能です。ただし、これは開発者の意図的な妨害行為であるという意見もある。

 
Renat Fatkhullin:

OrderExist と PositionExist は、シンボル、取引タイプ、medzhik によるエントリーを検索するために、すべての注文またはポジションをループすることを回避する特別な最適化関数です。

その結果、チケットの配列になります。


これらの機能を利用することで、プログラムが大幅に節約できる可能性があります。特に、オープンポジションやオーダーを一括して呼び出す場合、常にオーバーシュートループを繰り返しています。

今後、膨大な トレードデータにアクセスするための、より効果的な機能を実装していく予定です。

また、言語も飛躍的に強化・簡略化され、より強力な機能を搭載します。

Renatさん、Copy...関数を使うときにTERMINAL_MAXBARSの外側のクォートにアクセスできるようにしてほしいという大きな要望があります。少なくとも分単位の時間枠だけでも。また、このために別の機能を作ることもできます。
しかし、このデータにアクセスするためには、常にTERMINAL_MAXBARSをunlimitedに設定しなければならず（さらに、それはターミナルに過負荷をかける）、すべてのシンボルに対してunlimitedを必要としないので非常に不都合である。
私が理解する限り、すべての小さなMN1期間のバーをコピーしても、すべてのM1バーはダウンロードされますが、それらへのアクセスはありません。
もちろん、ティックはこの制限の対象ではないので、すべてのティックをダウンロードできますが、より時間がかかり、残念ながらティックはすべての分履歴と一致するとは限りません。

 
Nikolai Semko:

Renatさん、Copy...関数の使用時にTERMINAL_MAXBARSの外側のクォートにアクセスできるようにしてほしいという大きな要望があります。少なくとも分単位の時間枠だけでも。また、このために別の機能を作ることもできます。
しかし、このデータにアクセスするためには、常にTERMINAL_MAXBARSをunlimitedに設定しなければならず（さらに、それはターミナルに過負荷をかける）、すべてのシンボルに対してunlimitedを必要としないので非常に不都合である。
結局、私が理解する限り、すべての小さなMN1期間のバーをコピーすると、すべてのM1バーはとにかくダウンロードされますが、それへのアクセスはありません。
もちろん、ティックはこの制限の対象ではないので、すべてのティックをダウンロードできますが、より時間がかかり、残念ながらティックは常にすべての分履歴と一致するとは限りません。

いいえ、この制限外の履歴はピックアップされず、同期チェックされません。さらに、それらを保存する場所がない（目に見えないキャッシュを追加で作らない）、不経済なモードでディスクを登らない、松葉杖を作らない、などです。

開発者はすぐに絶対的に効率の悪いアルゴリズムを書き始め、トレーダーに「5000本か1000本のバーをセットするように」とアドバイスし、私たちのスピードの遅さや効率の悪さを非難するからです。

チャートに割り当てるリソースの量を意図的にコントロールできるようにしたのです。64ビットでメモリも安くなったので、ルールやアーキテクチャの中で適切な設定をしてください。

私たちは、この行動を変えることはありません。

 
Renat Fatkhullin:

いいえ、これらの制限の外側の履歴は発生せず、同期をチェックします。しかも、それらを保存する場所がなく（見えないキャッシュを追加で作らない）、不経済なモードでディスクをよじ登ることもない。

実際、開発者はすぐに絶対的に非効率なアルゴリズムを書き始め、トレーダーに「5000本か1000本のバーを設定するように」とアドバイスし、遅さと非効率さを非難するからです。

チャートに割り当てるリソースの量を意図的にコントロールできるようにしたのです。64ビットでメモリも安くなったので、ルールやアーキテクチャの中で適切な設定をしてください。

この行動は変えません。

オッケーです。了解です。ありがとうございます。Crossed out.
 もちろん、 不経済については論じたいけれど。 無制限にしておくと、結果的に全てのオープン（例えば私は今14個のチャートを持っています）が全ての履歴を残すことになりますが、私はそれらのほとんどに5000だけ必要なのです。逆にどちらが不経済になるか。
また、このデータは保存しておく必要はないですね。保管は私が行います。私はすべての分のバーのロードを開始し、それらを配列に取得し、私はもうそれを必要としないし、すべてのキャッシュは、そのサイズがTERMINAL_MAXBARSを超えた場合、削除することができます。だから、キャッシュを保存しない別の機能というのは、そういうことなのかもしれませんね。

もちろん、いたずらな手を使えば、そのような定期的な負荷でシステムが停止してしまうことは承知していますけれども。

 

5000とアンリミの2つの状態しかないんですか？

あなたは自分の幸せの主人です。

1...101112131415161718192021222324...94
新しいコメント