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

 
Yury Kulikov:
例えば、端末間通信。

まあ、そうやって捻じ曲げれば、もちろんDLLは便利な機能なんですけどね...。

今考えているのは、ある証券会社から見積もりを取って、別の証券会社にシグナルを送るEAで、MetaTraderも持っていないものなんです。(DucaCopi、ところで、MetaQuotesはこの老舗ブローカーに賛同するのだろうか ?)。

DLLの方向で考えていた。しかし、共有ファイルの方がより安全で合理的であると判断しました。MetaTraderにシグナルをファイルに書き込ませる。そして、別のMetaTrader(またはJForexや他の誰か)に読み込ませ、実行させるのです。

 

ところで、配列参照について考えてみたのですが...。

レナート 提案があります。

せっかくStandard Libraryが あるのだから、OnCalculate()関数の亜種を以下のプロトタイプで追加してはどうだろうか。

intOnCalculate(constint rates_total,//入力時系列の大きさ)
constint prev_calculated,// 前のコールで処理されたバー
const CiTime* ptTime,// 時間
const CiOpen* poOpen,// 開く
const CiHigh* phHigh,// ハイ
const CiLow* plLow,// Low
const CiClose* pcClose,// 閉じる
const CiTickVolume* ptvTickVolume,// ティックボリューム
const CiRealVolume* prvRealVolume,// 実体積
const CiSpread* psSpread// スプレッド
);

?

私見では、これはMetaTraderで非常に小さな変更を必要としますが、一方では、単に配列へのポインタを提供し、コピーなしでハンドラクラスに渡すことができます。そして、Standard Libraryという考え方そのものを普及させる。

 

実際の大規模プロジェクト(~2万行のソースコード)を例に、新旧コンパイラのパフォーマンスを比較した最初の結果を得ました。

旧バージョンのコンパイラでコンパイルしたプログラムの実行時間結果(4回実行)。

2015.05.02 13:48:46.641 *** (EURUSD,D1)       Start ***. Parsing of history deals (22575) and orders (22656) completed in 6.443 sec. 116 MB RAM used.
2015.05.02 13:48:27.879 *** (EURUSD,D1)       Start ***. Parsing of history deals (22575) and orders (22656) completed in 6.427 sec. 116 MB RAM used.
2015.05.02 13:48:12.067 *** (EURUSD,D1)       Start ***. Parsing of history deals (22575) and orders (22656) completed in 6.287 sec. 116 MB RAM used.
2015.05.02 13:47:49.719 *** (EURUSD,D1)       Start ***. Parsing of history deals (22575) and orders (22656) completed in 8.751 sec. 116 MB RAM used.

新バージョンのコンパイラでコンパイルしたプログラムの実行時間結果(4回実行)。

2015.05.02 13:54:18.638 *** (EURUSD,D1) Start ***. Parsing of history deals (22575) and orders (22656) completed in 5.475 sec. 116 MB RAM used.
2015.05.02 13:54:01.995 *** (EURUSD,D1) Start ***. Parsing of history deals (22575) and orders (22656) completed in 5.616 sec. 116 MB RAM used.
2015.05.02 13:53:43.853 *** (EURUSD,D1) Start ***. Parsing of history deals (22575) and orders (22656) completed in 5.444 sec. 116 MB RAM used.
2015.05.02 13:53:25.809 *** (EURUSD,D1) Start ***. Parsing of history deals (22575) and orders (22656) completed in 6.147 sec. 116 MB RAM used.

*2回目以降の実行は、温めたキャッシュで行い、温めたキャッシュは生産性を15-30%向上させることがわかりました。

20000件以上のディールとオーダーを解析するのに、最初の実行では6.4秒、2回目の実行では5.4秒かかり、15~20%の 性能向上が見られました。

性能向上はもっと大きくてもよかったのですが、ほとんどの時間をシステム関数呼び出しに取られています。

 

新しいコンパイラは、合計2万行以上のソースコードからエラーを検出しなかった。これは、このプロジェクトが古いバージョンのコンパイラ用に作成されたことを考慮すると、素晴らしい結果であると言えるでしょう。

しかし、新しいコンパイラーでは、ファイルパスの表示が正しくない(スラッシュのエスケープが必要)ことに関連する警告メッセージがいくつか表示されました。

これは妥当な要求であり、わずかな修正で容易に満たすことができます。

したがって、MQL5で書かれた大規模なプロジェクトでも新しいコンパイラに対応でき、プロの開発者にとっても切り替えは問題ないと結論づけることができます。

 
Sergey Eremin:
...
コード生成エラー1 1」と表示されるのですが。

...

また、このようなエラーも発生します。
 
主な収穫は、数学と自分自身の計算です。

ハードワークの大部分がシステムコールである場合、加速度は小さくなります。
 
Renat Fatkhullin:
主に数学と自分の計算で得をしています。

ハードワークの大部分がシステムコールである場合、加速度は小さくなります。

それでも良いのは、最小限のシステム関数呼び出しで独自の環境を構築できるからです。

(自分のクラスで一度環境をコピーして、直接作業する)。

 
George Merts:

まあ、そうやって捻じ曲げれば、もちろんDLLは便利な機能なんですけどね...。

今考えているのは、ある証券会社から見積もりを取って、別の証券会社にシグナルを送るEAで、MetaTraderも持っていないものなんです。(DucaCopi、ところで、MetaQuotesはこの老舗ブローカーに賛同するのだろうか ?)。

dllについて考えてみた。でも、共有ファイルを使う方が安全で賢明だと判断したんです。MetaTraderにシグナルをファイルに書き込ませる。そして、別のMetaTrader(またはJForex、または他の誰か) - 読んで実行させる。

名前付きチャンネル という選択肢もあるが、中間サーバーが必要である。

フォーラムには、その方法の例が掲載されています。

 
Yury Kulikov:
例えば、端末間通信。

アレクサンドル・ブリスガロフ

名前付きチャンネル という選択肢もあるが、中間サーバーが必要である。

フォーラムには、その方法の例が掲載されています。

名前付きチャンネルは必要ないSQLのサポートが追加されるのを待ちます。テーブルを介したデータのやり取り。SQLは、マルチスレッドで高負荷なシステムをビルトインでサポートします。
 
Vasiliy Sokolov:

名前付きチャンネルは不要ですSQLのサポート追加を待つテーブルを介したデータ交換。SQLは、マルチスレッドの高負荷システムをビルトインでサポートしています。
私はただ、今あるものについて話していただけで、もしSQLを追加すれば、それについても話すことができます )