私のアプローチコアはエンジンです。 - ページ 125

[Vladimir]

Реter Konow:

つまり、おっしゃるとおりに描き直されているわけです。

そして、プロセッサへの負荷は、アニメーションからもたらされます。

画素配列の値は常に再初期化されます。16ミリ秒ごと。これにより、プロセッサに最大40%の負荷がかかります。

具体的にどのような負荷がかかっているのか、考えてみました。リソースを保存したり、読んだりすることだと思いました。描画ループ内の配列の再初期化が原因であることが判明しました。

また、ObjectSetInteger(0, "MT object",OBJPROP_SELECTED,1); の定数呼び出し（16 ms毎）でもプロセッサをロードすることが判明した。約10％の差で。

この呼び出しを使って、別のEAにアニメーションデータの入ったリソースを読み込むように指示するのです。

アニメーション中はトータルで＋〜50％のCPU負荷がかかります。

すみません、オープントレードの一覧についてでなくなっていることに気がつきませんでした。なくなったのは、2-3ページのスレッドだと思います。

[Реter Konow]

Vladimir:
すみません、オープントレードの一覧についてでなくなっていることに気がつきませんでした。消えた、2-3ページ分のスレッドだと思う。

いや、いいんです。CPU負荷を持ち出したのは、EAとエンジンの通信をやり直すので、オープントレードのテーブルのデータの取り方も変わってくるからです。

[Nikolai Semko]

なぜ64コマ/秒（16ms）が必要なのか、目には32コマ/秒で十分なのです。

[Реter Konow]

Nikolai Semko:
なぜperirisを64フレーム/秒（16ms）にするのか、目には32フレーム/秒で十分です。

いい質問ですね。実は、タイマーがスムーズに作動しないんです。スキップがある。16,32,16,16...

32を使用した場合、スキップは64msとなります。そして、これは顕著です。そのほかにも、さまざまなことが負担となり、描画が遅くなってしまうのです。例えば、OnChartEvent()イベントキュー。

アニメーションの クオリティに影響すると思います。25msで試してみました。次に16、そして16の方が滑らかな動きを表現できるという結論に至った。

アニメーション16ミリ秒と32ミリ秒と後でskolnuyuエンジンは、あなた自身のために表示されます。とはいえ、もしかしたら大丈夫かもしれませんが...。

[Nikolai Semko]

Реter Konow:

いい質問ですね。実は、タイマーがスムーズに作動しないんです。スキップがある。16,32,16,16...

32を使用した場合、スキップは64msとなります。そして、これは顕著です。そのほかにも、さまざまなことが負担となり、描画が遅くなってしまうのです。例えば、OnChartEvent()イベントキュー。

アニメーションのクオリティに影響すると思います。25msで試してみました。次に16、そして16の方が滑らかな動きを表現できるという結論に至った。

アニメーション16ミリ秒と32ミリ秒と後でskolnuyuエンジンは、あなた自身のために表示されます。とはいえ、もしかしたら大丈夫かもしれませんが...。

ただ、本当は16msではなく、1000/64=15.625msなのですが。つまり、フレーム間のポーズを33msとすると、実際のポーズは15.625×3=46.875msとなります。

また、MTは独自の内部チャート更新ハンドラを持っているので、ChartRedrawは 非同期で動作し、MTがすべてを処理する保証はないことを忘れてはいけません。

[Алексей Тарабанов]

Nikolai Semko:
ただ、本当は16msではなく、1000/64=15.625msなんですけどね。つまり、フレーム間のポーズを33msとすると、実際のポーズは15.625×3=46.875msとなります。

そして、MTは独自の内部チャート更新ハンドラを持っているので、ChartRedrawは非同期で動作し、MTがすべてを処理する保証はないことを忘れてはいけません。

なぜ？シンプルで、面白い。

[Nikolai Semko]

Алексей Тарабанов:

なぜ？単純に、なんでしょうね。

私は、実験と科学的な試行錯誤を繰り返して、このような結論に至ったところです。もし、私の主張を反証するような実験をお持ちの方がいらっしゃいましたら、ぜひ教えてください。

[Реter Konow]

Nikolai Semko:
ただ、本当は16msではなく、1000/64=15.625msなんですけどね。つまり、フレーム間のポーズを33msとすると、実際のポーズは15.625×3=46.875msになります。

また、忘れてはならないのは、MTは独自の内部チャート更新ハンドラを持っているので、ChartRedrawは非同期に動作し、MTがそのすべてを処理する保証はないことです。

なるほど、それは考慮に入れておきます。

タイマーの周波数を下げれば、プロセッサの負荷は確実に減ります。アニメーションの クオリティを落とさないのであれば、素晴らしいことです。CPUの負荷は最大で30％軽減されるかもしれませんが、それでも

我慢してください。

確かに、描画を異なるスレッドに分散させれば（例えば、アニメーションの一部がExpert Advisorを描画し、エンジンの一部が描画する）、負荷はほとんどかからなくなるでしょう。考えないと...

[Реter Konow]

残念ながら、私の思い込みは裏切られた。

今、私はある実験をしました。1つのEAを2つのチャートに置いてみたのです。Expert Advisor はプロセッサに 50% の負荷をかけます。

違うチャートで作業しても、CPU負荷が合計され、MT側のCPUの負荷が合計で90％以上になっていることがわかりました。

そのため、異なるExpert Advisorでチャートを分割しても、何の役にも立ちません。負荷が加算される！？

[Nikolai Semko]

Реter Konow:

残念ながら、私の思い込みは裏切られた。

今、私はある実験をしました。1つのEAを2つのチャートに置いてみたのです。Expert Advisor はプロセッサに 50% の負荷をかけます。

違うチャートで作業しても、CPU負荷が合計され、MT側のCPUの負荷が合計で90％以上になっていることがわかりました。

そのため、異なるExpert Advisorでチャートを分割しても、何の役にも立ちません。負荷が加算される！？

MT4であれば、そうです。

MT5では、MT4とは対照的に、マルチコア、マルチスレッドに完全対応していると理解しています。