1

同じ操作を行うコードのチャンクが 2 つあります。1 つは自分で作成したチャンクで、もう 1 つはサード パーティが作成したチャンクです。どちらも単一の実行可能ファイルにコンパイルされます。サード パーティのコードは、私のコードよりもはるかに高速に処理できるようです。私の 500 と比較して、1 秒あたり 1,500 の操作を実行できます。次に、VTune 内で実行可能ファイルを実行し、callgraph プロファイリング オプションを使用して、時間を無駄にしている場所が明らかになることを期待しました。残念ながら、各関数にかかると考えられるマイクロ秒数を示す VTune 診断では、私の関数とサードパーティの関数の両方が呼び出しごとに約 0.002 秒かかっていると主張しています。これは私のコードでは問題ないように見えますが、サードパーティのコードの速度を (手動で) 測定した結果とは完全に一致していません。

これはどのように起こりますか？

編集: コードの両方のチャンクは大きく、サブ関数の独自の複雑なツリーを呼び出します。

編集:サードパーティのコードは純粋な C++ であるのに対し、私のコードは本質的に C++ コンパイラでコンパイルされたばかりの C コードであることを指摘しておく必要があります。

編集: VTune は非常に複雑なパッケージであり、理解できない構成オプションが多数あります。この不正確さを軽減するために使用できる設定がいくつかあるのではないでしょうか?

4

3 に答える 3

2

「真のタイミング」の定義は、修正が必要な場合があります。リンゴとナシを比較するとき、プロファイラーが間違っていると主張することはできません。

プロファイラーは相対的なタイミングに使用できます。プロファイラーを使用してコード内の「ホットスポット」を見つけ、その情報を使用してその領域を最適化します。

実用的なメモ: サンプリング プロファイラーを探してください。これは、通常、トレース/計測プロファイラーよりもオーバーヘッド/影響がはるかに少ないです。

(PS Schrodinger/Heisenberg についてもお読みください)

于 2011-04-19T12:17:15.003 に答える
0

プロファイラーが特定の関数/システム コールの報告された時間を人為的に膨らませるケースを見てきました。サードパーティのライブラリがそのような呼び出しを使用しており、それに釘付けになっている可能性があります。

高性能クロック ( gethrtimeSolaris またはQueryPerformanceCounterWindows) を使用して、サニティ チェックとして関数の合計時間を測定してみましたか?

あなたの操作は CPU バウンドのように非常に遅いように思えます。それらは I/O バウンドですか? あなたの I/O コードは、ライブラリよりも最適化されていませんか? これは、必ずしも CPU プロファイル レポートに表示されるとは限りません。

于 2011-04-19T13:40:29.760 に答える
0

経過時間 (つまり、CPU カウンターの代わりに経過秒数) を使用している場合は、システム コールのブロックに費やされた時間も考慮する必要があります。たとえば、ファイル I/O をあまり行っていないと仮定すると、コンソールに情報を出力するのに多くの時間を費やしている可能性があります。コンソール I/O は、CPU 時間としては表示されません。その時間のほとんどは、コンソールの更新を待っているだけだからです。

を使用GetThreadTimes(...)して、コードとシステム コードに費やしている時間を判断できます。これとシステム コール サンプリングを使用して、コンテキスト スイッチを減らしました (そして最終的に全体的なパフォーマンスを向上させました)。

于 2011-04-19T16:45:00.697 に答える