0

私が知っているすべての .net プロファイラーは、CPU キャッシュの影響を考慮していません。

CPU キャッシュからフィールドを読み取ると、メイン メモリから読み取るよりも 100 倍速くなる可能性があることを考えると、これは大きな要因になる可能性があります。（私は答えでこれを説明しなければなりませんでした）

プロファイラーが遅いと言うループを高速化するために長いタイマーを費やす人が多すぎるのを見てきました。

たとえば、データ アクセスで CPU キャッシュが不足しているかどうかを確認したり、より信頼できる基本的なプロファイリング結果を取得したりしたいと考えています。

過去に、データをよりコンパクトにすることですべてが CPU キャッシュに収まるか、データがアクセスされる他のキャッシュを変更すると大きな効果が得られることを発見しました。例えば

AccessArrarFromStartAndDoSomething()  
AccessArrayFromEndAndDoSomethingElse()

それなら良い

AccessArrarFromStartAndDoSomething()  
AccessArrayStartEndAndDoSomethingElse()

配列が CPU キャッシュに収まらない場合でも、そのタイプの改善を見つけるのは非常に困難です。

CPU キャッシュにうまく収まるようにデータを小さくするために CPU サイクルを増やすと、多くのシステムが分散する可能性がありますが、ほとんどのプロファイラーは別の方向を示します。

4

2 に答える 2

0

プロファイラーが遅いと言うループを高速化するために長いタイマーを費やす人が多すぎるのを見てきましたが、実際には CPU キャッシュがそれらを高速にします。

一部のプロファイラーは、そのようなナンセンスが本当に得意です。

あなたの全体的な目標は何ですか？実時間よりも短い時間で計算を完了したいですか?

そうでない場合は、この回答を無視してください。

もしそうなら、取り除くことができる壁時計の時間を費やしている原因を知る必要があります.

タイミングの正確さではありません。位置精度についてです。本当に知っておく必要があるのは、コードのどの行が 1) 費やされた時間の妥当な割合を占めているか、および 2) 改善できるか、またはまったくできないかということです。そのようなコード行がない場合、何を最適化するのでしょうか。

そのようなコード行を見つけるための優れた方法は、1)コール スタックの実時間 (CPU 時間ではなく)でサンプルを取得し、2)コードの各行(関数ではない) について、コール スタックに表示される、スタックの何パーセントに表示されるか。最適化の候補となる行は、割合が大きい行の中にあります。(いくつかの非 .net の例: ZoomとLTProf。)

率直に言って、私が使用するプロファイラーは、あなたがすでに持っているものです。プログラムが遅いときに一時停止して、スタックを確認します。たくさんのサンプルは必要ありません。実際、なくてもよいコード行があり、それがわずか2 つのサンプルに表示される場合は、修正する価値があることがわかります。そのポイントに到達するのに必要なサンプル数が少ないほど、コードは大きくなります。ここに、より完全な説明があります。

ほとんどの場合、複数の「ボトルネック」があります。だから私は大きなものを見つけて修正し、それをすべてやり直します。ボトルネックを修正すると、残りのボトルネックが大きくなります。この「拡大効果*」により、押し出す速度がなくなるまで続けることができます。

于 2010-07-30T13:15:35.923 に答える
0

私はあなたの質問を誤解しているかもしれませんが、答えは単にプロファイラーを高精度、低詳細モードに切り替えることだと思います。例として、ANTS Performance Profiler の新しいサンプリング モードを使用します。

http://www.simple-talk.com/community/blogs/andrew/archive/2009/11/13/76420.aspx

于 2010-07-30T11:54:48.713 に答える