PLOの華麗さと貧しさ - ページ 7

[Dmitry Fedoseev]

見つけた！結局、PLOでなんとか高速化。はい！そのメリットは否定できません。

[Dmitry Fedoseev]

dimeon:

じゃあ、全部アセンブリ言語で書こうよ。どうせなら、そのほうが早い。

問題がよくわからない。1MBのコードを持つExpert Advisorやインジケータを見たことがない。

また、関数の呼び出しにもある程度の時間がかかる。機能も捨てよう

大規模なプロジェクトのコントロールは、OOPでより便利になりました。

また、コードの実行速度は、ブローカーへのping送信時間やブローカーからの注文に対するレスポンスほど重要でないことが非常に多いのです。

HFTのアルゴリズムを見てみましょう。最高速度が要求されますが、そこには複雑な計算は見当たりません。

PS.A地点からB地点に移動するのに、普通はスーパーカーやスノーモービルは必要ありません。原付で十分です!

ここに一人、関数を書く代わりに、ファイルにコードを書いてインクルードしている人がいます。

[Alexey Navoykov]

Integer:

見つけた！結局、PLOでなんとか高速化。はい！そのメリットは否定できません。

では、その暗号は何だったのか。

[Dmitry Fedoseev]

meat:
では、その暗号は何だったのか。

iCustom() を、パラメータの数が異なる場合、パラメータの数ごとに異なるケース、またはOOPバリアントでパラメータの数ごとに異なるクラスで呼び出す こと。

[Renat Fatkhullin]

MQLコンパイラの新しいビルドでは、仮想メソッドチェーンの最終メソッドで、外部ライブラリへのリンクがない場合、仮想メソッドを直接呼び出しに置き換える最適化がすでに含まれています。

この方法は、クラスを扱う多くのプログラムの仮想コールを簡素化し、高速化する。

670ビルドの最初の投稿にあるtest.mq4の例の結果です。

switch: 172
OOP:    312

32〜64msという極小の時間計測では動作しないため、ループを1000万回から5000万回に増やさなければならなかった。時間がmsで表示され、数字が小さいほどコードが高速であることを示します。

同じコードに新しいコンパイラを適用したところ、このような結果になりました。

switch: 157
OOP:     93

OOPは快勝した。でも、なぜ？

まず、仮想メソッドを通常のメソッドにし、ジンラインを引いてゼロになるように最適化した。実際、関数の 呼び出しと本体は 完全に消え、純粋なループが残った。

  mov     int[i] <- int[0]

$label:
                                        <- тут когда-то было тело, но оно оптимизировалось в ноль
  add     int[i] <- int[i], int[1]
  jlt     int[i], int[50000000] --> $label

コンソールコンパイラの新しいベータ版を含むファイルが添付されています。MetaEditorの通常の670ビルド（コンパイラはビルトインされています）とコンソールコンパイラを使って、任意の例を比較することができます。

これが証明すること。

1. 試されているのは、コンパイラのオプティマイザの品質である。
2. テストは、実際にすべてがどのように最適化されているかを完全に理解した上で書かれるべきものである
3. 私が言ったように、コード最適化の特殊性を知らなければ、（OOPが突然勝つ）誤解を招く可能性があることを既存の例で示しました。