エラー、バグ、質問 - ページ 2285

 
Alexey Navoykov:

しかし、この場合の「速い」というのは、非常に相対的なものです。 ユーザーがバーの配列を要求するのは、単にメモリの一部をコピーしているだけです。 特定の時系列を要求する場合も、構造体のサイズと等しい一定のステップでデータをコピーしているだけです。そしてもうひとつは、各数値の上に計算や変換を追加していることです。

とはいえ、個人的には、どうせ保存用のアレイを自前で整理しているのだから、メモリを無駄にしないためにも、履歴は圧縮しておきたいところです。だから、少々の遅れは大目に見ています。しかし、他のほとんどのユーザーは、そのためにあなたを切り刻むでしょう )

p.s. 理想的なのは、端末で履歴をメモリに保存するモードを選択できるようなオプションがあるといいのですが。例えば、RAMが少なくても、高速なプロセッサがあれば、非常に有効です。

よく見てください。SDDの書き込み、読み出し速度を測定してみたところ。8バイト(1種類の値doubleまたはdatetimeまたはlong)の書き込みと読み出し時間は、〜48nsであることが判明した。また、私の計算では、パックアレーから8バイトの情報を読み出す時間は1〜2nsです。このように、構造体要素へのアクセスで1~2nsのロスが発生する一方で、ディスクへの書き込みと読み込みで48*0.8=38nsのロスが発生しています。さらに、5倍のRAMとディスク容量の節約を実現しました。 HDDについても黙っています。

 
Nikolai Semko:

よく見てください。SDDの読み込み、書き込み速度を測定したところ。8バイト(1種類の値doubleまたはdatetimeまたはlong)の書き込みと読み出し時間は、〜48nsであることが判明した。また、私の計算では、パックアレーから8バイトの情報を読み出す時間は、1-2nsです。このように、構造体要素へのアクセスで1~2nsのロスが発生する一方で、ディスクへの書き込みと読み込みで48*0.8=38nsのロスが発生しています。しかも、メモリとディスクの容量は5倍も節約できます。 HDDの話でもありません。

反論はしません。4年前、SSDがまだ一般的でなく、大半のユーザーが遅いHDDを使用していた頃、レナットとこのトピックについて議論したことがあるんです。そこで私は(SSDの例を挙げて)、HDDの動作はシステムの中で最も遅いリンクであり、そこから消費されるデータ量を最小限にするよう努めるべきであり、その逆ではない、と説得しました。 しかし彼は、CPUに余計な仕事をさせる必要はない、お前らは馬鹿で何も分かっていない、などと言い出しました。総じて、いつも通りです。)

確かに、最近はSSDがかなり加速していますね。

書き込みと読み出しの時間は8バイト であることが判明しました

しかし、なぜ書き込みと読み込みを一緒に測定しなければならないのか。 データは、サーバーから受信するとき、あるいはキャッシュを作成するときに一度だけ書き込むはずである。だから、カツは別、ハエも別。
 

トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム

バグ、バグ、質問

fxsaber さん 2018.09.10 21:28

まず、Optimizationのログです。

Tester  optimization finished, total passes 714240
Statistics      optimization done in 7 hours 31 minutes 06 seconds
Statistics      local 714240 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%)
Core 1  connection closed
Core 2  connection closed
Core 3  connection closed
Core 4  connection closed
Core 5  connection closed
Core 6  connection closed
Core 7  connection closed
Core 8  connection closed
Tester  714240 new records saved to cache file 'tester\cache\Test.FILTER_EURUSD.rann_RannForex.M1.20180226.20180909.40.2D734373DF0CAD251E2BD6535A4C6C84.opt'

この7.5時間の間、SSDにはものすごい頻度でアクセスが行われていたのです。仮に1回ごとにダニを読み取った場合、1秒間に平均26回、7.5時間の計算になる。それゆえ、このような乱暴な瞬き-70万回以上も読まれたのである。


シングルランログ

Core 1  FILTER_EURUSD.rann_RannForex,M1: 132843 ticks, 60283 bars generated. Environment synchronized in 0:00:00.140. Test passed in 0:00:00.827 (including ticks preprocessing 0:00:00.109).
Core 1  FILTER_EURUSD.rann_RannForex,M1: total time from login to stop testing 0:00:00.967 (including 0:00:00.140 for history data synchronization)
Core 1  322 Mb memory used including 36 Mb of history data, 64 Mb of tick data

見ての通り、130Kティックと60Kバーが使用されています(Testerでは "Entire history "モードが選択されています)。つまり、ごくわずかな歴史しかないのです。

端末のカスタムシンボルの履歴は、以下の量の履歴データが含まれています。

Saved ticks = 133331
Generated Rates = 60609

すなわち、シンボルの歴史において、テスターによって使用されるより非常に少ないです。


ZS SSDを見るのは残念ですが...。Optimiseはどこまで速くなるのでしょうか?非圧縮で7MB刻みなので、OSがこのデータをキャッシュしないのは不思議です。


SSDからではなく、メモリからデータを読み書きするように、RAM-diskにmklink経由でTerminalのどのフォルダを使用しますか?Optimisationでどのようなスピードアップが図れるのか、データを提供してもいいと思っています。

 
Nikolai Semko:

そう、これはアーカイブなんです。私の理解が正しければ、現在、ティックと分バーはパッケージ化されていない状態で保存されており、つまりバー(MqlRates構造体)については60バイト、ティック(MqlTick構造 体)については52バイトとなっているのです。
恐るべし!とっくにどうにかしているはずだ。

圧縮配列の主な問題は、配列の各要素に素早くアクセスするための構成であると理解しています。

しかし、配列の256番目の要素だけをアンパックして保存し、他の要素にはアンパックした要素への増分だけを保存したとしても、配列サイズは4-5倍になり、各要素へのアクセス時間はそれほど増加しない(1-2ナノ秒程度)にもかかわらず、ディスクからの保存とディスクへの読み込みにかかる時間は大幅に短縮されることが分かります。

"すべてはあなたの前にすでに盗まれている" (cz)

一日の始まりは、フルティックです。その後、入札および/または質問および/またはフリッパーフル、利用可能な場合は、他のすべてのインクリメント。1ティックあたり平均10バイト。

tickへのアクセスは厳密にシーケンシャルなので、配列の各要素に素早くアクセスできるように配置することに問題はありません。

 

Tester⇄cache⇄.opt "レコードのソースを掲載するようにとの大きな要求がある。内容を見ていただくとわかるのですが、フォーマットはとてもシンプルです。

Optimizationの結果を 使った仕事がとても必要です。ありがとうございました。

 

取引 回数が増えると、なぜかテスターの性能が落ちる。Expert Advisor側で取引履歴を参照することはない。

ということはないようです。

 

テスターでは、「全履歴」モードに対応したインターバルが記憶されます。カスタムシンボルに 履歴を追加し、Terminalをリロードしても、「All history」に対応する間隔が変化しないのですが。

デフォルトモードは変更できないが、全履歴を選択すると全履歴を手動で設定する。訂正してください。

 

マークされた場所に十字がない - キャッシュエントリーの対応する行を削除します。

最適化はたくさんしています。長い間、時代遅れになっているものもあります。また、これらのオプションを削除する仕組みはありません。時には、膨大なリストを手に入れ、不必要なバリエーションから探し始めることもあります。

そのため、不要なデータを削除する場合は、画像内のマークがある場所に十字を入れるなどしてご検討ください。

 
A100:
実行中のエラー

結果:true:false:7:4

長さの違う文字列が突然等しくなるのはなぜ?StringCompareを 使った比較では、逆の==結果が 得られるが

ご投稿ありがとうございます。文字単位の文字列比較の挙動を変更しました。

従来はZ-string(ヌル文字まで)として比較 されていましたが、PASCAL-string(長さを考慮した)として比較されるようになりました。

Z文字を含まない通常の文字列を持つ既存のコードには、この変更は適用されません。

 
Testerの大きな要望は、Last known lastが0であれば、Bid/Askでクローズすることです。