助けてください問題が解決できない、ハードウェアの限界にぶつかる - ページ 19 1...12131415161718192021 新しいコメント Nikolay Likhovid 2014.08.23 20:12 #181 komposter:だから、他の配列から数百万件の案件をこなす必要があるのですまさにその通りです。まあ、1つの数字（シーケンス番号）をチェックするという話ですから、こんな初歩的な操作で100万はないでしょう。基準を再帰的に数えると、ファイルを1回通すだけなので、どうせならもう一つ考慮すべきは、再帰データマップには同じ数百万個の要素（1シーケンスのパラメータ数を掛けたもの）が含まれることである。 もう一つの方法は、ソートの前に 条件を完全に再計算して保存することです。ここでも、再帰性を利用する可能性があることが重要です。操作数が多くなることは明らかですが、オリジナル版では少ないのでしょうか？ Eugeniy Lugovoy 2014.08.24 10:35 #182 ALXIMIKS:C++では、パーサがなくてもできる場合。このアイデアを10回繰り返すと、配列の開始位置の値を別のファイルで開始すれば、配列構造に取引 数を格納する必要さえなくなります。すでに述べたような普通のインデックスが表示されます。 Andrey Khatimlianskii 2014.08.27 23:15 #183 上で説明したアルゴリズムを実装してみました。X = 20 (20個のディールに対する基準計算) のデータを処理するのに約112分 かかりましたが、その大部分は配列シフトに費やされました (プロファイラによれば40%)。配列のループやその他の最適化を行った結果、処理が高速化されました。X=20の場合：48分X=50の場合：60分メモリは65トランザクション分（100万配列の掛け算）しかなかった。もちろん、これだけでは足りません。最低でも100は欲しいと思っていました。次に、取引に関する不要な情報をすべて廃棄することにした。始値、終値、利益（pips）だけを残して、X=185でなんとか離脱。次に - ファイルでの作業を高速化するだけで、FileReadXXXは現在30％の時間がかかります（そしてディスパッチャーはディスクでの作業はないと言っていますが、CPUは負荷がかかっています）。FileReadはFileSeekの後、まさに最初のもので、つまりシーケンシャルリードは高速に動作します。新しい結果が出たら、またお知らせします。kazakov.v: C++では、64K-128Kバッファのfreadで行われ、sscanf-esは非常に遅いので、独自のパーサーで解析するのがよいでしょう。サービスデスクからアドバイスされたWinAPIでファイルを操作してみることにします。ALXIMIKS私はアイデアを10回押している - 別のファイルのシーケンスの開始位置の値を持つ別のファイルを作成するには、シーケンスの構造でさえ取引の数を 格納する必要がなくなります。インデックスが何をするのか理解できない。トレード数を書いても違いはなく、順次読み込みはすぐに動作します、問題はファイルを移動した後のブロックを正確に読み込むことです。推奨アルゴリズムをお書きください。C-4:問題は非自明だが、まだコードは1行もない。アンドレイ ここにいる多くの人々が興味を持っています。スポーツ番組を編成しようデータを扱う一般的な原則を踏まえた上で、テストデータ＋疑似コードが必要です。タスクは最初から最後まで定式化されています。そして、テストデータは、先に掲載したスクリプトを少し修正したもので生成することができます。それはもう少し後にしよう。ジュ なぜ、ベースとなるオプションにこだわるのでしょうか？ 基準に従って履歴にトレードを生成する方が良いのでは？テストのためなら、もちろんそうですが、問題を解決するためなら、もちろんそうではありません )キャンディッド 1つの数字（シーケンス番号）をチェックするわけですから、こんな初歩的な操作で100万はないでしょう。基準を再帰的に考えれば、ファイルを1回通すだけで、とにかくやらなければならないことになる。もう一つ考慮すべきは、再帰データマップは同じ数百万要素（1シーケンスのパラメータ数を乗じた数）を含むということだ。もう一つの方法は、ソートの前に 条件を完全に再計算して保存することです。ここでも、再帰性を利用する可能性があることが重要です。いずれにしても操作数が多くなることは明らかですが、オリジナル版では少ないのでしょうか？初期のバリエーションでは、渡された履歴から最後の取引を見つける際に、一度だけ基準を計算することができます。そして、そのようなファイルの断片を、すべての 配列の情報がX個含まれるように読み取る必要があります。案件の量は様々で、均等に分散しているとは限らないので、X *配列数よりはるかに大きくなります。2すべて。とにかく、応援ありがとうございました。差し支えなければ、テストスクリプトを 実行し、結果を共有してください。 Andrey Khatimlianskii 2014.08.28 01:15 #184 komposter:そして、テストデータは、先に掲載したスクリプトを少し修正したもので生成することができます。更新されたスクリプトを添付します。このスクリプトは、同一の取引を記録するだけでなく、指定された設定（寿命- からとから、利益 - からとから）でランダムなシーケンスを生成するようになりました。私のものと同等のファイルを得るには、デフォルトの設定でスクリプトを実行してください。2014.08.28 04:12:36.044 sTest_ReadWriteBIN EURUSD,M15:140,000 secuences writown in57.1 sec. 2014.08.28 04:13:20.688 sTest_ReadWriteBIN EURUSD,M15:6632 Mb を44.0 秒で ロード(150.7 MB/秒)その後、その上でアルゴリズムを練り上げればいい。怠惰な人は、google driveに ファイルをアーカイブしてください。 ファイル: sTest_ReadWriteBIN.mq4 5 kb Nikolay Likhovid 2014.08.28 07:27 #185 komposter:1.オリジナルのバリエーションでは、パスした履歴から最後のディールを見つける際に、一度だけ基準を計算することができます。あなたのバリアントでは、すべての 配列のX個の情報を含むようなファイルを読み込む必要があります。案件の数が異なり、均等でない場合もあるので、X *配列数よりずっと大きくなる。1 これはあまり明確ではありません。もし最大（最小）基準を求めるのであれば、最終的にはやはりすべての候補について基準を計算する必要があります。局所的な極限か、世界的な極限かは関係ない。2.それよりも明らかに多いのは、必要なメモリの観点から許容できるサイズかどうかという問題です。さらに、ディスクの読み取り速度の点でも、ブロックサイズは大きいほうがいい。確かに、まだRAMの問題ではありません。読み取りは順次、一度だけ行うことが基本的に重要である。 しかし、ソートの前に条件を計算するバリアントは、2回読む必要があります。しかし、特にデータをいくつかの小さなファイルに分割し、その後の共同処理の可能性を考慮すると、それなりの利点があるのです。しかし、実装しなければ、すべての引数が抽象的なままである。というわけで、この際だから、私は失礼させていただきます :) Mykola Demko 2014.08.28 09:36 #186 komposter:どのビットがどのファイルの始まりで、どのビットが終わりなのか、インデックスを付けてファイルのスティッチングを行う方法。例えば、1000個のファイルから1000個のメタファイルを作成し、基準が分かっていれば、類似したファイルを1つのメタファイルに収める統計的順序付けを行う。大きなファイルを1000回開くのと小さなファイルを1000回開くのと、小さなファイルを1000000回開くのとでは、どちらが速いのでしょうか？その結果、ファイルをマージするのではなく、分割する必要があることが判明することもあります。 Andrey Khatimlianskii 2014.08.28 21:04 #187 Urain:どのビットがどのファイルの始まりで、どのビットが終わりなのか、インデックスを付けてファイルのスティッチングを行う方法。例えば、1000個のファイルから1000個のメタファイルを作成し、基準が分かっていれば、類似したファイルを1つのメタファイルに収める統計的順序付けを行う。大きなファイルを1000回開くのと小さなファイルを1000回開くのと、小さなファイルを1000000回開くのとでは、どちらが速いのでしょうか？ファイルをマージするのではなく、分割する必要があることが判明することもあります。現在、1つの大きなファイルで作業しているが、100万の小さなファイルにしたいと思った。第一に、追加できること、第二に、名前でアクセスできること（「各シーケンスの開始点」を保存する必要がない）です。私はサービスデスクで、異なるファイルを100万回開くことについて尋ねました（私はキャッシュをそのように実装しています）。その答えは、明快でわかりやすい。私は、1つの大きなファイルと100万個の小さなファイルの両方でAPI関数をテストし、結果を公表する予定です。キャンディッドしかし、実装しなければ、すべての引数は抽象的なままである。ですから、この時点で私が撤退するのが適切でしょう :)始めからそうしておけばよかった;)しかし、いずれにせよ、ご参加ありがとうございました。コードのないアイデアも貴重です。 Renat Fatkhullin 2014.08.28 21:53 #188 100万個のファイルで、あなたはntfsを泣くほど台無しにするでしょう。このマイクロソフトの非常識な発案は、ファイルシステムの非常識な遅い実装で皆を永遠に閉じ込めたのです。msがファイルシステムで行ったことはすべて、とんでもない重荷であり、遅滞であり、愚かさです。このバカどもは最適化とスピードアップの努力もせず、apiも原始的なものでしかない。2014年、これは明確に言えることです。よく、泣く。 Renat Fatkhullin 2014.08.28 21:58 #189 ウィンドウズでファイルの束を扱う効率を上げたい人は、まずチャンク（1つのファイル内でグループ化し、独自のデータ構造を 持つもの）に入ります。1000個以上（ましてや数万個、数十万個）の異種ファイルをWindowsに保存するようになったら、もうお手上げです。 Renat Fatkhullin 2014.08.28 22:05 #190 MQL4/5のファイル操作は、私たちの非常に効率的なキャッシュメカニズムを経由するため、非常に効率的で高速な読み取りと書き込みを実現することができます。バイト単位でデータを流すことができます。すべてのデータは内部バッファに素早く集められ、大きな塊でのみディスクに書き込まれます。WinAPIの呼び出し回数が少ないため、高速な動作が可能です。読み込みも同様で、積極的に動作し、大きな塊で読み込み、WinAPIをほとんど呼び出さず、最小限のオーバーヘッドで非常に迅速にキャッシュからデータを返します。大雑把に言うと、ビルド509と比較して、MQL4/5のファイル操作のスピードは一桁上がりました（「スピード測定を最大化するためにメガバイトブロックで書き込む」のではなく、通常のチャンクベース操作という意味であれば）。 1...12131415161718192021 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
だから、他の配列から数百万件の案件をこなす必要があるのですまさにその通りです。
まあ、1つの数字（シーケンス番号）をチェックするという話ですから、こんな初歩的な操作で100万はないでしょう。基準を再帰的に数えると、ファイルを1回通すだけなので、どうせならもう一つ考慮すべきは、再帰データマップには同じ数百万個の要素（1シーケンスのパラメータ数を掛けたもの）が含まれることである。
もう一つの方法は、ソートの前に 条件を完全に再計算して保存することです。ここでも、再帰性を利用する可能性があることが重要です。
操作数が多くなることは明らかですが、オリジナル版では少ないのでしょうか？
C++では、パーサがなくてもできる場合。
このアイデアを10回繰り返すと、配列の開始位置の値を別のファイルで開始すれば、配列構造に取引 数を格納する必要さえなくなります。
すでに述べたような普通のインデックスが表示されます。
上で説明したアルゴリズムを実装してみました。
X = 20 (20個のディールに対する基準計算) のデータを処理するのに約112分 かかりましたが、その大部分は配列シフトに費やされました (プロファイラによれば40%)。
配列のループやその他の最適化を行った結果、処理が高速化されました。
メモリは65トランザクション分（100万配列の掛け算）しかなかった。もちろん、これだけでは足りません。最低でも100は欲しいと思っていました。
次に、取引に関する不要な情報をすべて廃棄することにした。始値、終値、利益（pips）だけを残して、X=185でなんとか離脱。
次に - ファイルでの作業を高速化するだけで、FileReadXXXは現在30％の時間がかかります（そしてディスパッチャーはディスクでの作業はないと言っていますが、CPUは負荷がかかっています）。
FileReadはFileSeekの後、まさに最初のもので、つまりシーケンシャルリードは高速に動作します。
新しい結果が出たら、またお知らせします。
C++では、64K-128Kバッファのfreadで行われ、sscanf-esは非常に遅いので、独自のパーサーで解析するのがよいでしょう。
サービスデスクからアドバイスされたWinAPIでファイルを操作してみることにします。
私はアイデアを10回押している - 別のファイルのシーケンスの開始位置の値を持つ別のファイルを作成するには、シーケンスの構造でさえ取引の数を 格納する必要がなくなります。
インデックスが何をするのか理解できない。
トレード数を書いても違いはなく、順次読み込みはすぐに動作します、問題はファイルを移動した後のブロックを正確に読み込むことです。
推奨アルゴリズムをお書きください。
問題は非自明だが、まだコードは1行もない。アンドレイ ここにいる多くの人々が興味を持っています。スポーツ番組を編成しよう
データを扱う一般的な原則を踏まえた上で、テストデータ＋疑似コードが必要です。
タスクは最初から最後まで定式化されています。
そして、テストデータは、先に掲載したスクリプトを少し修正したもので生成することができます。
それはもう少し後にしよう。
なぜ、ベースとなるオプションにこだわるのでしょうか？ 基準に従って履歴にトレードを生成する方が良いのでは？
テストのためなら、もちろんそうですが、問題を解決するためなら、もちろんそうではありません )
キャンディッド
1つの数字（シーケンス番号）をチェックするわけですから、こんな初歩的な操作で100万はないでしょう。基準を再帰的に考えれば、ファイルを1回通すだけで、とにかくやらなければならないことになる。もう一つ考慮すべきは、再帰データマップは同じ数百万要素（1シーケンスのパラメータ数を乗じた数）を含むということだ。
もう一つの方法は、ソートの前に 条件を完全に再計算して保存することです。ここでも、再帰性を利用する可能性があることが重要です。
いずれにしても操作数が多くなることは明らかですが、オリジナル版では少ないのでしょうか？
初期のバリエーションでは、渡された履歴から最後の取引を見つける際に、一度だけ基準を計算することができます。
そして、そのようなファイルの断片を、すべての 配列の情報がX個含まれるように読み取る必要があります。案件の量は様々で、均等に分散しているとは限らないので、X *配列数よりはるかに大きくなります。
2すべて。
とにかく、応援ありがとうございました。
差し支えなければ、テストスクリプトを 実行し、結果を共有してください。
そして、テストデータは、先に掲載したスクリプトを少し修正したもので生成することができます。
更新されたスクリプトを添付します。このスクリプトは、同一の取引を記録するだけでなく、指定された設定（寿命- からとから、利益 - からとから）でランダムなシーケンスを生成するようになりました。
私のものと同等のファイルを得るには、デフォルトの設定でスクリプトを実行してください。
2014.08.28 04:12:36.044 sTest_ReadWriteBIN EURUSD,M15:140,000 secuences writown in57.1 sec.
2014.08.28 04:13:20.688 sTest_ReadWriteBIN EURUSD,M15:6632 Mb を44.0 秒で ロード(150.7 MB/秒)
その後、その上でアルゴリズムを練り上げればいい。
怠惰な人は、google driveに ファイルをアーカイブしてください。
komposter:
1.オリジナルのバリエーションでは、パスした履歴から最後のディールを見つける際に、一度だけ基準を計算することができます。
あなたのバリアントでは、すべての 配列のX個の情報を含むようなファイルを読み込む必要があります。案件の数が異なり、均等でない場合もあるので、X *配列数よりずっと大きくなる。
1 これはあまり明確ではありません。もし最大（最小）基準を求めるのであれば、最終的にはやはりすべての候補について基準を計算する必要があります。局所的な極限か、世界的な極限かは関係ない。
2.それよりも明らかに多いのは、必要なメモリの観点から許容できるサイズかどうかという問題です。さらに、ディスクの読み取り速度の点でも、ブロックサイズは大きいほうがいい。確かに、まだRAMの問題ではありません。読み取りは順次、一度だけ行うことが基本的に重要である。
しかし、ソートの前に条件を計算するバリアントは、2回読む必要があります。しかし、特にデータをいくつかの小さなファイルに分割し、その後の共同処理の可能性を考慮すると、それなりの利点があるのです。
しかし、実装しなければ、すべての引数が抽象的なままである。というわけで、この際だから、私は失礼させていただきます :)
どのビットがどのファイルの始まりで、どのビットが終わりなのか、インデックスを付けてファイルのスティッチングを行う方法。
例えば、1000個のファイルから1000個のメタファイルを作成し、基準が分かっていれば、類似したファイルを1つのメタファイルに収める統計的順序付けを行う。
大きなファイルを1000回開くのと小さなファイルを1000回開くのと、小さなファイルを1000000回開くのとでは、どちらが速いのでしょうか？
その結果、ファイルをマージするのではなく、分割する必要があることが判明することもあります。
どのビットがどのファイルの始まりで、どのビットが終わりなのか、インデックスを付けてファイルのスティッチングを行う方法。
例えば、1000個のファイルから1000個のメタファイルを作成し、基準が分かっていれば、類似したファイルを1つのメタファイルに収める統計的順序付けを行う。
大きなファイルを1000回開くのと小さなファイルを1000回開くのと、小さなファイルを1000000回開くのとでは、どちらが速いのでしょうか？
ファイルをマージするのではなく、分割する必要があることが判明することもあります。
現在、1つの大きなファイルで作業しているが、100万の小さなファイルにしたいと思った。
第一に、追加できること、第二に、名前でアクセスできること（「各シーケンスの開始点」を保存する必要がない）です。
私はサービスデスクで、異なるファイルを100万回開くことについて尋ねました（私はキャッシュをそのように実装しています）。その答えは、明快でわかりやすい。
私は、1つの大きなファイルと100万個の小さなファイルの両方でAPI関数をテストし、結果を公表する予定です。
しかし、実装しなければ、すべての引数は抽象的なままである。ですから、この時点で私が撤退するのが適切でしょう :)
始めからそうしておけばよかった;)
しかし、いずれにせよ、ご参加ありがとうございました。コードのないアイデアも貴重です。
100万個のファイルで、あなたはntfsを泣くほど台無しにするでしょう。このマイクロソフトの非常識な発案は、ファイルシステムの非常識な遅い実装で皆を永遠に閉じ込めたのです。
msがファイルシステムで行ったことはすべて、とんでもない重荷であり、遅滞であり、愚かさです。このバカどもは最適化とスピードアップの努力もせず、apiも原始的なものでしかない。2014年、これは明確に言えることです。よく、泣く。
ウィンドウズでファイルの束を扱う効率を上げたい人は、まずチャンク（1つのファイル内でグループ化し、独自のデータ構造を 持つもの）に入ります。
1000個以上（ましてや数万個、数十万個）の異種ファイルをWindowsに保存するようになったら、もうお手上げです。
MQL4/5のファイル操作は、私たちの非常に効率的なキャッシュメカニズムを経由するため、非常に効率的で高速な読み取りと書き込みを実現することができます。
バイト単位でデータを流すことができます。すべてのデータは内部バッファに素早く集められ、大きな塊でのみディスクに書き込まれます。WinAPIの呼び出し回数が少ないため、高速な動作が可能です。読み込みも同様で、積極的に動作し、大きな塊で読み込み、WinAPIをほとんど呼び出さず、最小限のオーバーヘッドで非常に迅速にキャッシュからデータを返します。
大雑把に言うと、ビルド509と比較して、MQL4/5のファイル操作のスピードは一桁上がりました（「スピード測定を最大化するためにメガバイトブロックで書き込む」のではなく、通常のチャンクベース操作という意味であれば）。