x64プラットフォーム用の新しいMQL5コンパイラーをテスト - 2~10倍計算が速い! - ページ 20

 
Denis Kirichenko:

ロジックを最適化する。例えば、配列やループを使った作業。基準値を配列にまとめてみる。そして、ループでチェックを行う。 その時は7万4千件もニーズがないのかもしれませんが......。

もちろん、理論的には、各文字列を長いハッシュで生成し、そのハッシュだけを渡して、それを使ってすべてを生成することも可能ですが、これが高速になるかどうかはわかりませんし、作業も単純ではありません......。

 
Alexey Kozitsyn:

1. そこに、コードの中で最も「遅い」場所が見えてきます。とはいえ...コンパイルに影響があるかどうかは別問題ですが......。

2.As you like:ケースを使用することができます。機能を細分化したほうがいいというアドバイスがありましたね。分解してテストする。はい、もちろん、コードは大きくなります。でも、どうしたらいいんだろう。

そして、ここではコードを関数に書き換えています - 付録にあります。

コンパイル後、前のコードが14428kbで、新しいコードが9447kbであることにすぐに気づきました - 5Mbytesの差にすでに驚いています - どこから!

さらにコンパイル速度によって、前者

0 error(s), 0 warning(s), 2109302 msec elapsed

ニューバージョン

0 error(s), 0 warning(s), 386131 msec elapsed

新バージョンでは、コンパイル速度が5.46倍に向上しています。

そして、こちらはスピードの面で前バージョンです。

2019.10.15 14:35:47.593 Core 1  pass 0 returned result 1001000.000000 in 0:00:29.555
2019.10.15 14:35:47.595 Core 3  pass 4 returned result 1001000.000000 in 0:00:29.490
2019.10.15 14:35:47.605 Core 2  pass 2 returned result 1001000.000000 in 0:00:29.540
2019.10.15 14:35:47.641 Core 4  pass 6 returned result 1001000.000000 in 0:00:29.541
2019.10.15 14:36:15.511 Core 2  pass 3 returned result 1001000.000000 in 0:00:27.907
2019.10.15 14:36:15.523 Core 1  pass 1 returned result 1001000.000000 in 0:00:27.932
2019.10.15 14:36:15.535 Core 3  pass 5 returned result 1001000.000000 in 0:00:27.942
2019.10.15 14:36:15.537 Core 4  pass 7 returned result 1001000.000000 in 0:00:27.897
2019.10.15 14:36:15.537 Tester  optimization finished, total passes 8
2019.10.15 14:36:15.547 Statistics      optimization done in 0 minutes 58 seconds
2019.10.15 14:36:15.547 Statistics      shortest pass 0:00:27.897, longest pass 0:00:29.555, average pass 0:00:28.725
2019.10.15 14:36:15.547 Statistics      8000 frames (3.14 Mb total, 412 bytes per frame) received
2019.10.15 14:36:15.547 Statistics      local 8 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)

新バージョンでは

2019.10.15 14:33:51.458 Core 3  pass 6 returned result 1001000.000000 in 0:01:01.840
2019.10.15 14:33:51.485 Core 2  pass 4 returned result 1001000.000000 in 0:01:01.867
2019.10.15 14:33:51.521 Core 1  pass 2 returned result 1001000.000000 in 0:01:01.903
2019.10.15 14:33:51.524 Core 4  pass 0 returned result 1001000.000000 in 0:01:01.906
2019.10.15 14:34:18.802 Core 3  pass 7 returned result 1001000.000000 in 0:00:27.346
2019.10.15 14:34:18.837 Core 2  pass 5 returned result 1001000.000000 in 0:00:27.354
2019.10.15 14:34:18.892 Core 4  pass 1 returned result 1001000.000000 in 0:00:27.370
2019.10.15 14:34:18.922 Core 1  pass 3 returned result 1001000.000000 in 0:00:27.403
2019.10.15 14:34:18.922 Tester  optimization finished, total passes 8
2019.10.15 14:34:18.932 Statistics      optimization done in 1 minutes 29 seconds
2019.10.15 14:34:18.932 Statistics      shortest pass 0:00:27.346, longest pass 0:01:01.906, average pass 0:00:44.623
2019.10.15 14:34:18.932 Statistics      8000 frames (3.14 Mb total, 412 bytes per frame) received
2019.10.15 14:34:18.932 Statistics      local 8 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)

そしてここで、エージェントの最初のパス(4エージェント)が非常に遅いことがわかります。何度も試してみましたが、結果は安定していますが、ログでは

2019.10.15 14:38:07.002 Tester  OnTesterInit works too long...

今更ですが、@Renat Fatkhullin さんか@Slava さんなら、なぜそのような効果が発生するのか、教えてくれるかもしれませんね。

ファイル:
 
Andrey Khatimlianskii:

ファイルはzip圧縮されています。ジッパーを読む、中のジッパーを開ける。500MBのEAを転送するよりも高速になります(各エージェントにも転送されます)。

その後、新しいパスが通るたびに、また解凍されるのでは?

はい、そして、ファイルからの読み込みは、1回限りの転送よりも速いでしょうか...。

 
Aleksey Vyazmikin:

その後、新しいパスが作られるたびに、また解凍されるのでは?

はい、それと、ファイルからの読み込みはシングルパスより速いでしょうか...。

たしかに、最適化すると遅くなるかもしれませんが...。しかし、私は確認します、すべてがそのために設定されています。

 
Andrey Khatimlianskii:

そうですね、最適化中は遅くなるかもしれませんね...。しかし、私は確認します、すべての準備が整っていることを。

レディとは一体何なのか......理解できない。

 
Aleksey Vyazmikin:

レディとは一体何なのか......理解できない。

zip アーカイブを扱う。

 
Andrey Khatimlianskii:

zip アーカイブを扱う。

はい、見たことはあるのですが、実際に試してみたことはないです。

それよりも、データ準備、つまりコードを表に変換することの方が問題ですね。生データをもう一度加工しなければならないので......。

 
残念ながら、コンパイラは大きなコードに対応できないことが判明し、"EX5 write error "というエラーが発生しました。ユーザーマニュアルに制限事項が書いてあると良いのでは!?
 
EAのパブリックバージョンを作って、今チェックしています - コンパイルできるかどうか - プロセスは速くないですが、今あなたはコードの46%がコンパイルされ、すでに36GBのRAMが消費されていることを見ることができます...。
 
Aleksey Vyazmikin:
EAのパブリックバージョンを作って、今チェックしています - コンパイルできるかどうか - プロセスは速くないですが、今あなたはコードの46%がコンパイルされ、すでに36GBのRAMが消費されていることを見ることができます...。

調査するためのコードを提供してください。
なぜコンパイルが遅く、メモリを大量に消費するのか調べてみます。