PLOの華麗さと貧しさ - ページ 5

新しいコメント
 
meat:

ここでは、私の理解では、インデックスはバイナリ検索によって定義されるのでしょうか？

いいえ、配列のように直接アクセスします。

__________

私が間違っていたのかもしれない、よく考えてみるよ。

一般に、型全体のサイズ分の配列を作り、常時アクセスを得ることを妨げるものはない。(スイッチは積分型のみ動作します）。

ご指摘のケースでは、列挙して入力する方が便利です。

 
TheXpert:

いいえ、配列のように直接アクセスします。

__________

大げさだったかもしれない、もう一度よく考えてみるよ。

一般に、型全体のサイズ分の配列を作り、常時アクセスを得ることを妨げるものはない。(スイッチは積分型のみ作動します）。

ご指摘のケースでは、列挙型を作成した方が便利です。

型の全数値に対して？まさか！？この場合、16Gbのメモリが必要になります（int型の配列の場合）。 また、値全体を取得することに何の意味があるのでしょうか？最大値と最小値の差を計算すればよいのですが、値が大きい場合は、まず、プログラムに割り当てるメモリの量をユーザーと交渉しなければならないので、いずれにしても疑問です。 そのため、キー値が小さい場合（というか最大値と最小値の差が小さい場合）しか適していません。これで残るはバイナリサーチのみ。

 
meat:

これで残るはバイナリサーチのみ。

いや、本当に必要ないんです。要するに、数値と数値の対応付けが必要な場合はバイナリサーチ、数値を扱って数値と数値の対応付けができれば十分な場合は定数サーチが必要ということです。

メモリのことはよくわかりました））だから、やりすぎたと書いたのです。

 

オンラインとテスターでスプレッドチャートを見比べながら、「なぜ？テスターは現実とは関係ない...。

tol64:

すでにどこかでもっと詳しい説明（証明）をされているのでしょうか？

自分の発言は証拠で裏付けしないと見向きもされない。;)

 
C-4:
みんな、スイッチのドキュメントを 読めよ。良いスイッチとは、その性能が選択肢の数に依存しないスイッチトランジションである。1つの選択肢、100、1000、その移行率は一定になります。
ワウサンクス、良い参考になりました、楽しく読んで得した気分です。
 
dimeon:

オンラインとテスターでスプレッドチャートを見比べながら、「なぜ？テスターは現実とは関係ない...。

注目を集めるため。新 しいスレッドを立てて、あなたの質問をより詳しく取り上げてください。リアルでどうなのか、テスターでどうなのかを示す。この問題に対するあなたの解決策を提示してください。そうでなければ、「チャンスも選択肢もない」ままだ。)
 
Vinin:

証拠は向こうからやってくる。あるいはまた、ただの言葉。

大体、私は事実にしか興味がないんです。

OOPの方が遅いということはすでに知っていますが、かなり具体的な利便性を提供しています。

約束通り、あるプロジェクトのプロファイリング結果を並べます。(一般向けではないため、一部機能が黒く塗りつぶされていますが、ご容赦ください）。

まず最初に、このプロジェクトは、ソースデータの強力な変換を伴う、真のOOPプロジェクトであることをお伝えします。その中でOOPを使うという発想は、絶対的なものを持っています。例えば、グローバル変数、配列、クラスの外の関数などは全く使いません。そのためには、全期間にわたって行われた注文や取引の履歴が必要です。6014件の取引と6599件の注文の解析にはわずか3.1秒、1取引あたり0.25ミリ秒しかかからず、すべての取引、注文、ポジションを展開するためには約13MB、つまり1取引あたり平均1キロバイトのRAMが必要です。- これはOOPアプリケーションとしては非常に良い結果だと思います。

2014.07.07 12:44:33.464 TestMA (AUDCAD,H1) 始まりました。履歴の取引（6014）と注文（6599）の解析が3.104秒で完了しました。13MBのRAMを使用。

しかし、アプリケーションの初期化時にかかる時間の構造を見てみよう。

ほとんどの時間がAddNewDeal関数の呼び出しに費やされていることがわかる。これは複合関数であり、実際の作業はRecalcValues（57％）に委ねられている。また、HistoryOrderGetIntegerなどのシステム関数で構成されています。

なお、これらの関数の呼び出し時間はほぼ等しくなっています。

注意すべきは、これで機能のコンベア全体が終了することです。これらの計算を行う前に、さらに何十もの中間的なOOP-メソッドを渡す必要があり、そのうちのいくつかは仮想的でもあります。しかし、その実行時間はごくわずかで、プロファイラではリストの後半に位置しています。

100％OOPのアプリケーションなので、タイムクリティカルなコードセクションの追跡が非常に簡単で、パフォーマンスを向上させる新しい方法を非常に効果的に見つけることができます。残りの部分（43％）は、80～90％がCArray.Resize()の呼び出しで構成されていることは既に知っています。コードが最適化されておらず、配列の再分割が必要以上に頻繁に発生する箇所があります。これらのOOPモジュールを簡単に書き換えて、25％～30％の性能向上を図ることができるんだ。なぜなら、各機能は無限の相互関係にある可能性があり、そのような機能を変更した場合の結果を計算することは非常に難しくなるからです。

その結果、複雑なOOPプロジェクトであっても、基本的なシステム機能の性能の限界に達することがあることがわかりました。し かし、OOPがなければ、そのような生産性を達成することはより困難になります。なぜなら、あまりにも多くの関数があるため、遅かれ早かれ間違いを犯すことになるでしょう。不要な呼び出しや最適化されていないツイン、または複雑で面倒な実装のどちらかを行ってしまうのです。

 
dimeon:

オンラインとテスターでスプレッドチャートを見比べながら、「なぜ？テスターでは現実とは関係ないのですが...。

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

OOPの栄光と汚点

tol64, 2014.07.07 09:12

注目を集めるため。新 しいトピックを立てて、質問を詳しく説明してください。実際にどうなのか、テスターでどうなのかを示す。この問題に対するあなた自身の解決策を提案してください。そうでなければ、「チャンスも選択肢もない」ままだ。)

+++

todimeon - スレッドを開けば、なぜできないのか、なぜすべきなのか、たくさんの議論を学ぶことができます。

 
C-4:

約束通り、あるプロジェクトのプロファイリングの結果を掲載します。(失礼ながら、一般向けではないので、一部の機能はマスクされています）。

...

このスレッドでは、OOPと手続き型プログラミングのパフォーマンスを比較することが目的です。そして、あなたの秘密の機能は、いくつかの仕事を実行し、どこかに何かを委任し、いくつかの時間がかかり、あなたは見事にこのすべてを処理することになっているという事実 - もちろん、我々はあなたのために信じられないほど幸せですが、我々はコードを見ないと、この情報は何の役に立つのでしょう。

 
meat:

この話題は、OOPプログラミングと手続き型プログラミングの性能比較に特化したものです。そして、あなたの秘密の機能は、いくつかの仕事を実行し、どこかに何かを委任し、いくつかの時間がかかり、あなたは見事にこのすべてを管理することになっているという事実 - もちろん、我々はあなたのために信じられないほど幸せですが、我々はコードを見ないと、この情報は何の役に立つのでしょう。

彼は、実際のプロジェクトにおいて、ダイレクトコールやバーチャルコールは何の効果もないことを示しました。

実際のOOPプロジェクトのプロファイリングを例に、限界時のパフォーマンスがシステム関数呼び出しのパフォーマンスと同じ傾向に あることを紹介します。

コストの大半は、MQLプログラムが最も時間を費やすシステム関数の呼び出しで発生しています。通話を手配するコストは、ペイロードに比べれば微々たるものです。

1234567
新しいコメント