MT5とスピードの関係 - ページ 71

 
fxsaber:

ここで実践と交わることのない理論付けは、これで終わりにしましょうと提案します。

それなら、無意味なシングルスレッドでの同期テストもやめたらどうでしょう。
並行した結果を期待する。

 
fxsaber:

問題は何一つ解決していない。内部変数が異なるスレッドからreadwriteアクセスされる場合など、MQLプログラムはより複雑なものになります。

ただ、MQL6はC++ではなく、Erlangに近いはずです )

 
Roman:

それなら、無意味なシングルスレッドでの同期テストもやめたらどうでしょう。
並行した結果を期待する。

ほぼ毎ティックで 大きなラグが発生しているのが気になる。スレッドとは関係ない。開発者はそれを理解している。

 
Aleksey Nikolayev:

ただ、MQL6はC++ではなく、Erlangに近いはずです )

となると、Scalaの方が良いですね。

....しかし、どう考えても、動的型付けを備えた強力な関数型言語の ラッパーの向こう側には......。イベントループのあるJavaは、別の銀河系から来たもので、計算機システムの拡張性とスケーラビリティを得るためには、分散マルチプロセッサシステムが必要です。

学校では

- ボボチカ、チキンフルーフの使い方を教えてください。

- どうだろう。

- さて、あなたは何の上で寝ますか?

- フロアに

- そして、頭を乗せるのは?

- フェルトのブーツに

- そして、ご両親はどんな風に寝ているのでしょうか?

- フロアに

- そして、その頭を乗せるのは?

- バレンキについて。

- そして、おばあちゃんはどんな風に寝ているのでしょうか?

- ストーブの上で。

- そして、彼女が頭を乗せるのは?

- 枕の上に。

- そして、枕の中には、毛羽立ちが?

- そして枕元にはバレンキが。

 
Igor Makanu:

Scalaの方が優れている

....しかし、どう考えても、動的型付けを備えた強力な関数型言語の ラッパーの向こう側には......。Pythonがその証拠で、イベントループで議論されているjavaは、計算システムの拡張性とスケーラビリティを得るために分散マルチプロセッサシステムを持たなければならない別の銀河系から来たものです。

それが、PythonはC言語で書かれていて、Pythonにはイベントループモデルをベースにしたasyncioライブラリがあります。
スワスの逸話はこのくらいにして ))

 
Igor Makanu:

となると、Scalaの方が良いですね。

メインはVHDLでコンパイルして自作サーバーを作ること)

 

Pythonとの連携スピードはもちろん重要な問題ですが、EAの実行速度に影響を与える基本的な問題はたくさんあります。

私は、関数 OnTradeTransaction の最後のコールである TRADE_TRANSACTION_HISTORY_ADD において、構造体 MqlTradeTransaction と MqlTradeResult のフィールドが実質的に空であるという問題に注目することを提案します。この欠陥を修正すれば、実行されたオーダーに関する網羅的な値を得るために不必要にHistoryOrderSelectを呼び出す必要がなくなるので、戦闘の実行速度がすでに向上しているはずです。

そして全体として、Mqlコミュニティレベルでは、このギャップがなくなることで、現在のOnTradeTransactioの実装の欠点を回避するためにExpert Advisorで様々な松葉杖を作るのに必要な労力を大幅に削減することにつながります。

問題は、MQチームにどのように影響を与えるかです。 この機能の欠点を解消するために、別の投稿で投票と署名を集めるとか?

 
Sergey Lebedev:

問題は、MQの開発チームにどのように影響を与えるかです。

私のレシピはうまくいきそうです:簡潔なコードで問題を再現することです。

 
Sergey Lebedev:

Pythonとの連携スピードはもちろん重要な問題ですが、EAの実行速度に影響を与える基本的な問題はたくさんあります。

OnTradeTransaction関数で TRADE_TRANSACTION_HISTORY_ADDの最後の呼び出しでMqlTradeTransactionとMqlTradeResult構造体のフィールドがほとんど空である、つまり、注文がその後履歴タブに反映される方法とヘルプ/ドキュメントにファイルされている方法に類似して充填されていない問題に焦点を当てることを提案します。この欠陥を修正すれば、実行されたオーダーに関する包括的な値を得るために不必要にHistoryOrderSelectを呼び出す必要がなくなるので、戦闘の実行速度がすでに向上しています。

そして全体として、Mqlコミュニティレベルでは、このギャップがなくなることで、現在のOnTradeTransactioの実装の欠点を回避するためにExpert Advisorで様々な松葉杖を作るのに必要な労力を大幅に削減することにつながります。

問題は、MQチームにどのように影響を与えるかです。 この機能の欠点を解消するために、別の投稿で投票と署名を集めるとか?

Pythonの例を理解していないことは、非同期の議論全般を理解していないことを示しています。
Pythonは イベントドリブンモデルの良い例です。そして、イゴールさんの逸話はまさに的を得ています。
そして、開発者が例の意味を把握していれば、どこを掘ればいいのかがわかるのです。
遅かれ早かれタイムリーな結果が得られるという期待は、同期実行モデルにかかっている。
mqlではそれが実現しました。この言語の可能性は非常に豊かですが、人為的に同期実行に制限されています。
 

Roman:
Не понимание примера с Python, говорит о не понимании обсуждения асинхронности в целом.

わかってないのはお前だ、スレを荒らすな。