MT5とスピードの関係 - ページ 69 1...626364656667686970717273747576...94 新しいコメント Roman 2020.11.04 20:48 #681 Andrei Trukhanovich:1スレッドでの並列処理というのは、どのように想定しているのでしょうか。 イベントループです。 そして一般的に、なぜすべてが1つのスレッドで実行されるのか、それは開発者の問題なのです。 Market Overviewは非同期、ユーザープログラム内のハンドラは同期で処理されていることがわかりました。 まさにシカルダス、言葉もない。 fxsaber 2020.11.04 22:14 #682 スタッツのご感想ありがとうございますOnTick/OnBookのラグは、誰にでもあるようです。Sleep(1)は1msまたは15msのいずれか。なぜ依存するのか、その理由は不明です。 pivomoe 2020.11.05 01:34 #683 fxsaber:皆さんOnTick/OnBookのラグがあるようです。 OnTimer()が10-16ミリ秒以上の頻度で呼ばれないことはご存知だと思います。 他のOnXXX関数もそれ以上の頻度で呼ばれないと考えるのが自然でしょう。もしかしたら、それが原因でラグが発生しているのでは？ Renat Fatkhullin 2020.11.05 02:35 #684 pivomoe:OnTimer()が10-16ミリ秒以上の頻度で呼ばれないことはご存知だと思います。 他のOnXXX関数もそれ以上の頻度で呼ばれないと考えるのが自然でしょう。もしかしたら、それがラグを生む原因かも？ 論理的ではなく、ハンドラはGetTickCountタイマーの周波数/解像度と結びついていない。イベントが発生した瞬間に、瞬時にトリガーされます。 OnTimerも16msの誤差に縛られることはない。コンピュータが死んでいて100％負荷がかかっていない限り、大半のケースで1msのタイマーを得るのは簡単です。 fxsaberのほぼすべてのテストの問題は、セットを平均化するのではなく、単一のコールの異常値を測定しようとすることであり、スレッドディスパッチャの現実を理解しようとしないことです。 彼は持っています。 4/8コアで1500～2000スレッド以上 スレッドマネージャは、非常に少数のアクターにスレッドを分散させるので、自分のタスクには何百もの競合 相手がいることに気づきません。 時折、優先度の高いスレッドが立ち上がり、短時間で他のスレッドより多くの時間を消費します。 どのスレッドも、いつ何時、谷からかなりの 時間離れるかわからない--それは些細なi++でミリ秒だ（何度言えばわかるのだろう）。 リールタイムに近づくための戦い方。 スレッドマネージャーを破壊するために、より多くのコアを 最新のキャッシュを搭載し、優れたクロックスピードとIPCを向上させた、間違いなく新しいCPUです。 より高速なメモリとnvmeディスクの採用により、サードパーティーの食欲の影響を劇的に排除しています。 ドライバとバイオを修正し、ありふれたネットワークインターフェイスが黙って割り込みを妨害しないようにする（特に仮想マシンでは、ISP管理者が問題に気づかないばかりか、レイテンシ、SR-IOV、デブロッキング/アンロックのボトルネックについて一般によく知らないので、とんでもないことになります）。 OSやプログラムインターフェイスのレンダリングによる2Dの負荷を軽減できる中型のディスクリートグラフィックカード（サーバーや仮想デスクトップでは常に負担となる）。 未使用プロセス／プログラム数の減少 不要な周辺ハードウェアやドライバの削減 そのため、通常のVPSでは、ターミナル（他のプログラムも同様）が常に予期せぬ遅延に悩まされることになります。安売り・売れすぎのVPSほど問題が多い。 あなたのVPSで、SR-IOVが有効になっているか、最新の（手動インストールのみの）特別なネットワークドライバがあるか、自問してみてください。ハードウェアズー間での仮想化の移行ができなくなるため、99％のケースで「いいえ」です。そして、それがなければ、（ホストと仮想の）2重のネットワークパケット転送/処理と割り込みの増加により、さらなる遅延が保証されることになります。 当社のVPSサービスは、アーキテクチャの 面でも、GUIを使わない軽量な端末の面でも、その傾向が非常に少ないです。 Roman 2020.11.05 04:34 #685 Renat Fatkhullin:論理的ではなく、ハンドラはGetTickCountタイマーの周波数/解像度に関連していない。イベントは、発生した時点で即座にトリガーされます。OnTimerも16msエラーに縛られない。コンピュータが死んで100％負荷がかからない限り、大半のケースで1msのタイマーを得るのは簡単です。 fxsaberのほぼすべてのテストの問題は、セットを平均化するのではなく、単一のコールの異常値を測定しようとすることであり、スレッドディスパッチャの現実を理解しようとしないことです。 彼は持っています。 4/8コアで1500～2000スレッド以上 スレッドマネージャは、非常に少数のアクターにスレッドを分散させるので、自分のタスクには何百もの競合 相手がいることに気づきません。 時折、優先度の高いスレッドが立ち上がり、短時間で他のスレッドより多くの時間を消費します。 どのスレッドも、いつ何時、谷からかなりの 時間離れるかわからない--それは些細なi++でミリ秒だ（何度言えばわかるのだろう）。 リールタイムに近づくための戦い方。 スレッドマネージャーを破壊するために、より多くのコアを 最新のキャッシュを搭載し、優れたクロックスピードとIPCを向上させた、間違いなく新しいCPUです。 より高速なメモリとnvmeディスクの採用により、サードパーティーの食欲の影響を劇的に排除しています。 些細なネットワークインターフェースが静かに割り込みを妨害しないように、ドライバとバイオを修正する（特に仮想マシンでは、ISP管理者が問題に気づかないだけでなく、一般的にレイテンシ、SR-IOV、デボトルネッキングについてよく知らないので大変なことになります）。 オペレーティングシステムとプログラムインターフェイスのレンダリングによる2D負荷を軽減することができる平凡なディスクリートグラフィックカード（サーバーや仮想デスクトップでは常に負担となる）。 未使用プロセス／プログラム数の減少 不要な周辺機器とそのドライバの削減 そのため、通常のVPSでは、ターミナル（他のプログラムも同様）が常に予期せぬ遅延に悩まされることになります。安売り・売れすぎのVPSほど問題が多い。 あなたのVPSで、SR-IOVが有効になっているか、最新の（手動インストールのみの）特別なネットワークドライバがあるか、自問してみてください。ハードウェアズー間での仮想化の移行ができなくなるため、99％のケースで「いいえ」です。また、ホストと仮想の2重のネットワークパケット転送/処理と割り込みの増加により、遅延が発生することが保証されています。 当社のVPSサービスは、アーキテクチャも GUIなしの軽量な端末も、桁外れにその対象です。 そして、このような最適化されたマシンにおいて、プログラム中のハンドラを非同期で実行した場合、ユーザープログラムのパフォーマンスは何倍遅くなるか想像してみてほしい。 ユーザプログラムのハンドラがあらかじめ同期的に実行されるのであれば、マシンハードウェアの超高性能化、超最適化の意味がわからない。 端末そのものやその内部構造については、おそらく、上記のような最適化が有効なのでしょう。 ユーザープログラムのハンドラの連続実行は、せっかくの超最適化マシンのポテンシャルを低下させるからです。 問題は、ハードウェアではなく、端末の内部作業のアーキテクチャにあるのです。 Slava 2020.11.05 06:30 #686 Roman:さらに、プログラム中のハンドラを非同期で実行するようにすれば、ユーザーのプログラムの実行が何倍速くなるか、想像してみてください。 ユーザプログラムのハンドラがあらかじめ同期的に実行されるのであれば、マシンハードウェアのスーパーアップグレードやスーパーオプティマイズの意味がわからないのですが。 端末そのものやその内部構造については、おそらく、上記のような最適化が有効なのでしょう。 ユーザープログラムのハンドラの連続実行は、せっかくの超最適化マシンのポテンシャルを低下させるからです。 問題は、ハードウェアではなく、端末の内部動作のアーキテクチャにあるのです。 加速度はありません。倍速加速度を証明する計算を、少なくとも概算値で提出してください。 資源の奪い合い？無秩序に新しいスレッドが作られる？何でもないことで対立する？ 原因不明のスローダウンをしたいのですか？ イベントベースモデルでは、すべてのイベントは常に1つずつ形成されて行っています。チューイングアップ - チューイングアップ。 fxsaber 2020.11.05 06:42 #687 Renat Fatkhullin:当社のVPSサービスは、アーキテクチャの 面でも、GUIを使わない軽量な端末の面でも、その傾向が非常に少ないのです。 VPSサービスでラグが発生した場合、真摯に対応していただけるのでしょうか？ MQのVPSを使っている人、そこで以下のプログラムの結果を教えてください。 OnTick/OnBookに遅れるExpert Advisorを キャッチ。 古くからあるティックをキャッチするExpert Advisor。 Sleep(1) の平均実行時間を測定するスクリプト です。 fxsaber 2020.11.05 06:42 #688 どうしたらSleep(1) を速く走らせることができますか？ Renat Fatkhullin 2020.11.05 06:53 #689 fxsaber:VPSサービスにラグがある場合、あなたはそれを真剣に受け止めますか？ 限られたコア数に対して多くの（数千）スレッドがある中で、スレッドごとの時間量子割り当ての安定性を語るのは全く正気の沙汰ではない、と何度言えばわかるのだろうか。 inc eaxのような最も単純なアセンブラの命令も含めて、どのような 命令でもランダムに1回サンプルすると必ず失敗 する。これは、アーキテクチャ的にも、「素直に数千スレッドの時間クアンタを少数のコアに割り当てる」という物理的な限界によるものです。 馬鹿なこと言ってないで、100万リクエストあたりのシングルバーストを捕捉し続けろ。 fxsaber 2020.11.05 07:00 #690 Renat Fatkhullin:バカなこと言ってないで、100万クエリに1個の異常値をキャッチし続けろ。 シングルスパイクの意味がわかりました、詳しい説明ありがとうございました。現時点では、SymbolInfoTickについて議論しているのではなく、ほとんどすべてのティックで 発生する別の種類のラグについて議論しているのです。 1...626364656667686970717273747576...94 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
1スレッドでの並列処理というのは、どのように想定しているのでしょうか。
イベントループです。
そして一般的に、なぜすべてが1つのスレッドで実行されるのか、それは開発者の問題なのです。
Market Overviewは非同期、ユーザープログラム内のハンドラは同期で処理されていることがわかりました。
まさにシカルダス、言葉もない。
スタッツのご感想ありがとうございますOnTick/OnBookのラグは、誰にでもあるようです。Sleep(1)は1msまたは15msのいずれか。なぜ依存するのか、その理由は不明です。
皆さんOnTick/OnBookのラグがあるようです。
OnTimer()が10-16ミリ秒以上の頻度で呼ばれないことはご存知だと思います。 他のOnXXX関数もそれ以上の頻度で呼ばれないと考えるのが自然でしょう。もしかしたら、それが原因でラグが発生しているのでは？
OnTimer()が10-16ミリ秒以上の頻度で呼ばれないことはご存知だと思います。 他のOnXXX関数もそれ以上の頻度で呼ばれないと考えるのが自然でしょう。もしかしたら、それがラグを生む原因かも？
論理的ではなく、ハンドラはGetTickCountタイマーの周波数/解像度と結びついていない。イベントが発生した瞬間に、瞬時にトリガーされます。
OnTimerも16msの誤差に縛られることはない。コンピュータが死んでいて100％負荷がかかっていない限り、大半のケースで1msのタイマーを得るのは簡単です。
fxsaberのほぼすべてのテストの問題は、セットを平均化するのではなく、単一のコールの異常値を測定しようとすることであり、スレッドディスパッチャの現実を理解しようとしないことです。
彼は持っています。
リールタイムに近づくための戦い方。
そのため、通常のVPSでは、ターミナル（他のプログラムも同様）が常に予期せぬ遅延に悩まされることになります。安売り・売れすぎのVPSほど問題が多い。
あなたのVPSで、SR-IOVが有効になっているか、最新の（手動インストールのみの）特別なネットワークドライバがあるか、自問してみてください。ハードウェアズー間での仮想化の移行ができなくなるため、99％のケースで「いいえ」です。そして、それがなければ、（ホストと仮想の）2重のネットワークパケット転送/処理と割り込みの増加により、さらなる遅延が保証されることになります。
当社のVPSサービスは、アーキテクチャの 面でも、GUIを使わない軽量な端末の面でも、その傾向が非常に少ないです。
論理的ではなく、ハンドラはGetTickCountタイマーの周波数/解像度に関連していない。イベントは、発生した時点で即座にトリガーされます。
OnTimerも16msエラーに縛られない。コンピュータが死んで100％負荷がかからない限り、大半のケースで1msのタイマーを得るのは簡単です。
fxsaberのほぼすべてのテストの問題は、セットを平均化するのではなく、単一のコールの異常値を測定しようとすることであり、スレッドディスパッチャの現実を理解しようとしないことです。
彼は持っています。
リールタイムに近づくための戦い方。
そのため、通常のVPSでは、ターミナル（他のプログラムも同様）が常に予期せぬ遅延に悩まされることになります。安売り・売れすぎのVPSほど問題が多い。
あなたのVPSで、SR-IOVが有効になっているか、最新の（手動インストールのみの）特別なネットワークドライバがあるか、自問してみてください。ハードウェアズー間での仮想化の移行ができなくなるため、99％のケースで「いいえ」です。また、ホストと仮想の2重のネットワークパケット転送/処理と割り込みの増加により、遅延が発生することが保証されています。
当社のVPSサービスは、アーキテクチャも GUIなしの軽量な端末も、桁外れにその対象です。
そして、このような最適化されたマシンにおいて、プログラム中のハンドラを非同期で実行した場合、ユーザープログラムのパフォーマンスは何倍遅くなるか想像してみてほしい。
ユーザプログラムのハンドラがあらかじめ同期的に実行されるのであれば、マシンハードウェアの超高性能化、超最適化の意味がわからない。
端末そのものやその内部構造については、おそらく、上記のような最適化が有効なのでしょう。
ユーザープログラムのハンドラの連続実行は、せっかくの超最適化マシンのポテンシャルを低下させるからです。
問題は、ハードウェアではなく、端末の内部作業のアーキテクチャにあるのです。
さらに、プログラム中のハンドラを非同期で実行するようにすれば、ユーザーのプログラムの実行が何倍速くなるか、想像してみてください。
ユーザプログラムのハンドラがあらかじめ同期的に実行されるのであれば、マシンハードウェアのスーパーアップグレードやスーパーオプティマイズの意味がわからないのですが。
端末そのものやその内部構造については、おそらく、上記のような最適化が有効なのでしょう。
ユーザープログラムのハンドラの連続実行は、せっかくの超最適化マシンのポテンシャルを低下させるからです。
問題は、ハードウェアではなく、端末の内部動作のアーキテクチャにあるのです。
加速度はありません。倍速加速度を証明する計算を、少なくとも概算値で提出してください。
資源の奪い合い？無秩序に新しいスレッドが作られる？何でもないことで対立する？
原因不明のスローダウンをしたいのですか？
イベントベースモデルでは、すべてのイベントは常に1つずつ形成されて行っています。チューイングアップ - チューイングアップ。
当社のVPSサービスは、アーキテクチャの 面でも、GUIを使わない軽量な端末の面でも、その傾向が非常に少ないのです。
VPSサービスでラグが発生した場合、真摯に対応していただけるのでしょうか？
MQのVPSを使っている人、そこで以下のプログラムの結果を教えてください。
VPSサービスにラグがある場合、あなたはそれを真剣に受け止めますか？
限られたコア数に対して多くの（数千）スレッドがある中で、スレッドごとの時間量子割り当ての安定性を語るのは全く正気の沙汰ではない、と何度言えばわかるのだろうか。
inc eaxのような最も単純なアセンブラの命令も含めて、どのような 命令でもランダムに1回サンプルすると必ず失敗 する。これは、アーキテクチャ的にも、「素直に数千スレッドの時間クアンタを少数のコアに割り当てる」という物理的な限界によるものです。
馬鹿なこと言ってないで、100万リクエストあたりのシングルバーストを捕捉し続けろ。
バカなこと言ってないで、100万クエリに1個の異常値をキャッチし続けろ。
シングルスパイクの意味がわかりました、詳しい説明ありがとうございました。現時点では、SymbolInfoTickについて議論しているのではなく、ほとんどすべてのティックで 発生する別の種類のラグについて議論しているのです。