助けてください問題が解決できない、ハードウェアの限界にぶつかる - ページ 15

 

ようやく必要なものがわかったので、このバージョンが最終版になることを願っています。

というように、Everythingは分割して平行移動させるだけの簡単なもので、主な手順は以下の通りです。

1. a. 各シーケンスの始まりと終わりが分かると非常に便利です(このため、前回、サイズを別のファイルに書き込むことを提案しました)。

б.自分で解析することもできますが、この場合、ディスクからファイルの次の部分を読み込むときに、前の切り取られたシーケンスを読み込むために戻ってくる必要があります。

次に、変形例1.aを考えてみます。おそらく、最適ではないでしょうが、私はこの方が好きです。

2.配列のサイズとファイルの一部のメモリサイズ(500 mb)がわかれば、ダウンロードするファイルの一部のサイズを計算することができます。

3.並行して、各シーケンスの始まりと終わりが分かっているので、シーケンスに対する係数を計算する。

4.各シーケンスの先頭と末尾をマルチスレッドキューに格納可能(ステップ2の計算中に充満)

5.計算結果 - 構造体 (構造体からの配列。時刻と係数+配列番号))

6.割り当てられたメモリの 初期サイズの半分(250 mb)が処理されると、始まりと終わりを持つ2番目のキューが形成され、書き換えの処理が開始されます

7.1行目の終わりに到達したら2行目から読み、2行目の終わりに到達したら1行目から読みます。

8.係数の計算とファイルからの読み込みを同時に行うことができます。

9.しかし、係数の計算結果はそれぞれ保存しなければならないので、レスポンスに一度にマージした方が良い。

2つの係数の列を1つのサブ結果に、2つのサブ結果を少し完全な1つのサブ結果に、それぞれマージする関数を書かなければなりません。

10.また、マージ処理は並行して行うことができます。

11.結果はいつ?アドオンファイルから読み込んだ配列のサイズが終了すると、2つのスタックが空になり、係数の計算が終了します。

の場合、サブリザルトプロセスのマージが終了するのを待つ必要がある(スレッドセーフキューを使用して行うことも可能)

そして最後に、異なるスレッドのサブ結果をマージする - 結果。


ここでは、可能な限り最大の負荷をかけたバリエーションを紹介します。

機能が欲しい。

入力列から係数列を形成すること

2つの係数列を1つのサブ結果にマージする(ここで精度が落ちる可能性がある)。

2つのサブリザルトを1つの完全なサブリザルトにマージする(精度が落ちる可能性があります)。

 
komposter:

巧妙な部分装填機構を発明することは可能だと思いますが、発明しなければなりません。

例えば、最初の読み取りで、各パスについて、開始日前に終了した最後の取引を見つけ、戻ってX回前の取引を読み取り、その取引が終了したファイルのポイントを記憶します。

その後、結果の最初の取引を見つけ、その後、新鮮なデータでのみ動作:目的のポイントから新しい実際の日付にファイルを読み、毎回配列(固定サイズの配列を取得 - X要素)の情報をシフトします。

これで、多重読み出しの問題(必要ないだけ)と、メモリの問題(X百万トランザクションを配置できる場合のみ)を解決することができます。

そう、それがアルゴリズムになるのです。

  1. 全ての案件の配列をX個の要素にリサイズする。
  2. Set SeekDate = StartDate.
  3. ファイルを開き、読み込みを開始し、最初のパスのディールの配列に順次充填する。
  4. 通過に対応する案件が終了した場合(X案件が少ない)、基準値=N/Aに設定し、次の通過に移行する。
  5. 取引番号(X+1)に到達したら、それまでの取引をすべて後ろにずらす(#1は破棄、#2は#1、#X+1は#Xになる)。
  6. 取引開始時刻 >= 取引開始時刻(配列に追加されない)。
    • 過去に追加された取引#1~#Xの基準値を計算する
    • 基準値を記憶する
    • 取引前のファイルポインタの位置を記憶する
    • 次のシーケンスに進む
  7. 最後のシーケンスが処理された場合。
    • 配列の中から最適なCriterion値を探す
    • ファイル内のベストシーケンスの最後のトレードがあるポジションに移動する
    • ファイルから案件を読み込み、配列に追加する(前の案件はシフトされる)。
    • ファイルポインタの位置を記憶する
    • 取引内容を結果ファイルに書き込む
    • Set SequentialDate = ディールクローズタイム + 1
    • 配列はすでに埋まっていて、読み出しは記憶したところから続けるという条件付きで、配列をループし続けるのです。

X万トレード分のメモリを確保することができれば(構造 体のサイズはあらかじめ分かっている)、一回で読み取ることができるようになる。

もしそうでなければ、リターン毎に最後のX個のディールの読み取りをリメンバードポインタに追加する必要がある。そうすると、ファイルは何度も読み込まれますが、それでも経済的です。

Nos、Trades[X]、Criterion、FilePointerの位置という配列構造が固定されます。不必要なものは何もない。

あとはコーディングするだけです =)

 

より望ましい結果は何か。

dllまたはまだmqlを計算する?

 

そうです、この形式ではタスクは並列です。SeekDateが変わるたびに、シーケンスセットの異なる部分に対して最適なCriterionを同時に検索 することができるのです。例えば、20個のパーツに分け、20人のExpert Advisorにタスクを与える。そして、ファイルを読み、取引を見つけ、最適なシーケンス(№、Criterion、ファイル位置)だけを送り返すべきである。

皆さん、本当にありがとうございました。

 
ALXIMIKS:

より望ましい結果は何か。

dllまたはまだmqlを計算する?

もちろん、より良いmqlを。また、DLLを書く意味もなく、MTでも並列化が可能です。
 

私はmqlを使い始めて半年も経っていないので、ちょっと頭が悪いかもしれませんが、間違っていたら指摘してください。

Открываем файл, начинаем читать, последовательно заполняя массив сделок первого прохода 

各パスのディスクからの読み込みを個別に行う予定ですか?ディスクから10^6回読み込む?

一度にまとめて読むのではなく、個別に読むというヒマはないのでしょうか?それとも、ここではすべてが最高レベルで実装され、バッファリングもしっかり確保されているのでしょうか?

もし、取引開始時刻が >= SeekDate である取引に到達したら(それは配列に追加されない)

  • Set SeekingDate = ディールクロージングタイム + 1
  • 配列はすでに埋め尽くされており、読み出しは保存された点から継続されるという唯一の注意点を除き、配列をループし続けます。

どこでメモリが解放されているのかわからない、どんどん溜まっていく。

  • 配列の中から最適なCriterion値を探す

なぜ、1つのクライテリオンのために全アレイを保持するのか?新しい基準を計算するときに比較し、適切なものを残すだけでよいのです。

もし、最適な10個の条件を見つけたいなら、10個の条件の配列を作り、そこに値を入れてソートし、バイナリサーチで 次の条件を挿入するのがよいでしょう。

 
ALXIMIKS:

各パスでディスクから別々に読み出しを行う予定ですか?ディスクから10^6回読み出す?

いずれにせよ、ファイル全体を読まなければならない。一度に(最初から最後まで)読むことはできないので、断片的に読むことになる(それでも最終的には全部のファイルを読むことになるのだが)。

ALXIMIKS

全編を一気に読むのではなく、1枚ずつ読むというヒマはないのでしょうか?それとも、ここではすべてが最高レベルで実装され、バッファリングもしっかり確保されているのでしょうか?

チャンクが読み込まれる。チャンクのサイズは、シーキング・デイト以前のトランザクションのうち、特定のシーケンスにあるトランザクションの数によって決定されます。

ALXIMIKS

どこでメモリが解放されているのかわからない、どんどん溜まっていく。

メモリは配列構造体の配列に対して一度だけ確保される。

シーケンス構造体は、No.、シーケンスの全トランザクションの構造体配列[X]、基準値、ファイルポインタ位置から なる。

次のステップは、構造要素(ディールの配列を含む)の充填だけである。配列内のディールはシフトされるため、メモリ上には常に各配列のX個のディールしか存在しない。

ALXIMIKS

もし、最適な10個の条件を見つけたいなら、10個の条件の配列を作り、そこに値を入れてソートし、バイナリサーチを使って次の条件を挿入する方がよいでしょう。

パラレリング用も含む。

しかし、ディール構造の配列を含む構造から1つのダブルを排除しても、タスクの枠組みの中では違いはない。

 

研究成果を共有する

7529MBのバイナリキャッシュファイルが読み込まれる。

  • ハードディスクから:212.3秒(35.46MB/秒)
  • RAMディスクから:88.1秒 (85.46 MB/秒)
一番多いハードディスクを搭載しているのに、この差はコスパがいいとは言い難い(とはいえ、メモリも速くはないのだが)。

結論:RAMディスクを使用して1つの大きなファイルを読み込む際の速度は約2.5倍となった。

 

もし、ファイルを配列内ではなく、グローバルに(全配列で)お得な時間でソートすると、次のようなアルゴリズムが可能になる。

- トレードの基準を計算し、候補とする

- この案件の内部で始まる案件の基準を計算し、最適なものがあれば候補を変更し、得られなかった場合は候補が選ばれたとみなし、その終了日から新しいサイクルを開始するのです。

また、クローズタイムでソートすることも可能です。

基準値を計算するためには、ファイルに各取引のシーケンス番号が含まれていなければならないことは明らかである。

このようなファイルの再ソートも面白くないでしょうから、一旦「ちゃんと」書いてみるのも手です。つまり、シーケンス全体を1つずつ生成するのではなく、シーケンスごとに1つのトランザクションを生成し、書き込み時にインテリジェンスに何らかのキャッシュを使用するのである。もちろん、生成アルゴリズムによっては、これは受け入れがたいことかもしれない。

 
Candid:

もし、ファイルが配列内ではなく、グローバルに(全配列で)取引された時間でソートされていれば、このようなアルゴリズムが可能である。

- 案件の基準を算出し、候補として検討する

そのようなファイルを記録するとします(現在のものを変換するだけなので、パソコンで15時間かかっても構いません)。

しかし、そこで--1つ目のポイントに--支障が出るのです。このようなファイルを持っていて、シーケンスの最後のXトレードのCriterionをどのように計算すればよいのでしょうか?

繰り返しになるが、クライテリオンは一度だけ計算することはできず、そのパラメータは変更される可能性がある。