x64プラットフォーム用の新しいMQL5コンパイラーをテスト - 2～10倍計算が速い! - ページ 20 1...13141516171819202122 新しいコメント Aleksey Vyazmikin 2019.10.15 11:49 #191 Denis Kirichenko: ロジックを最適化する。例えば、配列やループを使った作業。基準値を配列にまとめてみる。そして、ループでチェックを行う。 その時は7万4千件もニーズがないのかもしれませんが......。 もちろん、理論的には、各文字列を長いハッシュで生成し、そのハッシュだけを渡して、それを使ってすべてを生成することも可能ですが、これが高速になるかどうかはわかりませんし、作業も単純ではありません......。 Aleksey Vyazmikin 2019.10.15 11:58 #192 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 さんなら、なぜそのような効果が発生するのか、教えてくれるかもしれませんね。 ファイル: Tree_Brut_TestPL_F_Fast_Fun.zip 2719 kb Aleksey Vyazmikin 2019.10.15 12:00 #193 Andrey Khatimlianskii: ファイルはzip圧縮されています。ジッパーを読む、中のジッパーを開ける。500MBのEAを転送するよりも高速になります（各エージェントにも転送されます）。 その後、新しいパスが通るたびに、また解凍されるのでは？ はい、そして、ファイルからの読み込みは、1回限りの転送よりも速いでしょうか...。 Andrey Khatimlianskii 2019.10.15 22:35 #194 Aleksey Vyazmikin: その後、新しいパスが作られるたびに、また解凍されるのでは？ はい、それと、ファイルからの読み込みはシングルパスより速いでしょうか...。 たしかに、最適化すると遅くなるかもしれませんが...。しかし、私は確認します、すべてがそのために設定されています。 Aleksey Vyazmikin 2019.10.15 22:41 #195 Andrey Khatimlianskii: そうですね、最適化中は遅くなるかもしれませんね...。しかし、私は確認します、すべての準備が整っていることを。 レディとは一体何なのか......理解できない。 Andrey Khatimlianskii 2019.10.15 23:58 #196 Aleksey Vyazmikin: レディとは一体何なのか......理解できない。 zip アーカイブを扱う。 Aleksey Vyazmikin 2019.10.16 01:11 #197 Andrey Khatimlianskii: zip アーカイブを扱う。 はい、見たことはあるのですが、実際に試してみたことはないです。 それよりも、データ準備、つまりコードを表に変換することの方が問題ですね。生データをもう一度加工しなければならないので......。 Aleksey Vyazmikin 2019.10.16 08:13 #198 残念ながら、コンパイラは大きなコードに対応できないことが判明し、"EX5 write error "というエラーが発生しました。ユーザーマニュアルに制限事項が書いてあると良いのでは！？ Aleksey Vyazmikin 2019.10.16 20:16 #199 EAのパブリックバージョンを作って、今チェックしています - コンパイルできるかどうか - プロセスは速くないですが、今あなたはコードの46％がコンパイルされ、すでに36GBのRAMが消費されていることを見ることができます...。 Ilyas 2019.10.16 20:25 #200 Aleksey Vyazmikin: EAのパブリックバージョンを作って、今チェックしています - コンパイルできるかどうか - プロセスは速くないですが、今あなたはコードの46％がコンパイルされ、すでに36GBのRAMが消費されていることを見ることができます...。 調査するためのコードを提供してください。 なぜコンパイルが遅く、メモリを大量に消費するのか調べてみます。 1...13141516171819202122 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ロジックを最適化する。例えば、配列やループを使った作業。基準値を配列にまとめてみる。そして、ループでチェックを行う。 その時は7万4千件もニーズがないのかもしれませんが......。
もちろん、理論的には、各文字列を長いハッシュで生成し、そのハッシュだけを渡して、それを使ってすべてを生成することも可能ですが、これが高速になるかどうかはわかりませんし、作業も単純ではありません......。
1. そこに、コードの中で最も「遅い」場所が見えてきます。とはいえ...コンパイルに影響があるかどうかは別問題ですが......。
2.As you like：ケースを使用することができます。機能を細分化したほうがいいというアドバイスがありましたね。分解してテストする。はい、もちろん、コードは大きくなります。でも、どうしたらいいんだろう。
そして、ここではコードを関数に書き換えています - 付録にあります。
コンパイル後、前のコードが14428kbで、新しいコードが9447kbであることにすぐに気づきました - 5Mbytesの差にすでに驚いています - どこから!
さらにコンパイル速度によって、前者
ニューバージョン
新バージョンでは、コンパイル速度が5.46倍に向上しています。
そして、こちらはスピードの面で前バージョンです。
新バージョンでは
そしてここで、エージェントの最初のパス（4エージェント）が非常に遅いことがわかります。何度も試してみましたが、結果は安定していますが、ログでは
今更ですが、@Renat Fatkhullin さんか@Slava さんなら、なぜそのような効果が発生するのか、教えてくれるかもしれませんね。
ファイルはzip圧縮されています。ジッパーを読む、中のジッパーを開ける。500MBのEAを転送するよりも高速になります（各エージェントにも転送されます）。
その後、新しいパスが通るたびに、また解凍されるのでは？
はい、そして、ファイルからの読み込みは、1回限りの転送よりも速いでしょうか...。
その後、新しいパスが作られるたびに、また解凍されるのでは？
はい、それと、ファイルからの読み込みはシングルパスより速いでしょうか...。
たしかに、最適化すると遅くなるかもしれませんが...。しかし、私は確認します、すべてがそのために設定されています。
そうですね、最適化中は遅くなるかもしれませんね...。しかし、私は確認します、すべての準備が整っていることを。
レディとは一体何なのか......理解できない。
レディとは一体何なのか......理解できない。
zip アーカイブを扱う。
zip アーカイブを扱う。
はい、見たことはあるのですが、実際に試してみたことはないです。
それよりも、データ準備、つまりコードを表に変換することの方が問題ですね。生データをもう一度加工しなければならないので......。
EAのパブリックバージョンを作って、今チェックしています - コンパイルできるかどうか - プロセスは速くないですが、今あなたはコードの46％がコンパイルされ、すでに36GBのRAMが消費されていることを見ることができます...。
調査するためのコードを提供してください。
なぜコンパイルが遅く、メモリを大量に消費するのか調べてみます。