1

私が理解している限り、サンプリング プロファイラーは次のように動作します。定期的にプログラムの実行を中断し、コール スタックを読み取ります。プログラムのどの部分が現在実行されているかを記録し、プログラムのこの部分を表すカウンターをインクリメントします。後処理ステップ: プログラムの各関数について、関数が担当する実行時間全体の比率が計算されます。これは、この特定の関数のカウンター C とサンプルの総数 N を調べることによって行われます。

関数の比 = C / N

ホットスポットは、プログラムの中で比率の高い部分であるため、簡単に見つけることができます。

しかし、並列ハードウェア上で実行される並列プログラムに対してこれを行うにはどうすればよいでしょうか。私の知る限り、プログラムの実行が中断されると、すべてのプロセッサでプログラムの実行部分が決定されます。そのため、並行して実行される関数は複数回カウントされます。したがって、この関数のサンプル数 C は、実行時間全体のシェアを計算するために使用できなくなります。

私の考えは正しいですか？並列プログラムのホットスポットを特定する方法は他にありますか? それとも、サンプリングを使用してこれを行うことはできないのでしょうか?

4

1 に答える 1

1

あなたは正しい軌道に乗っています。すべてのスレッドをサンプリングする必要があるかどうかは、スレッドが同じことを行っているか、別のことを行っているかによって異なります。それらすべてを同時にサンプリングすることは必須ではありません。アイドル状態だけでなく、実際に動作しているスレッドを確認する必要があります。いくつかのポイント:

  • 不必要な I/O やその他のブロッキング コールを無視したい場合を除き、サンプリングはCPU 時間ではなく壁時計時間で行う必要があります。

  • どの関数がスタックにあるかだけでなく、どのコード行が費やされているかという目的を伝えるため、関心があります。「ホットスポット」よりも「ホットな目的」を探す方が便利です。

  • 関数またはコード行のコストは、それが表示されるサンプルのほんの一部です。これを理解するために、合計 N 個のサンプルに対して 10 ミリ秒ごとにサンプルが取得されるとします。関数またはコード行を非表示にできる場合、それがスタック上にあるすべてのサンプルも非表示になり、N がその分だけ減少します。それがスピードアップです。

  • 最後の点にも関わらず、サンプリングでは質が量に勝ります。目標がスピードアップの機会を理解することである場合、10 ～ 20 個のサンプルを手動で精査して、各瞬間が費やされている理由を完全に理解することで、さらに速くなります。そのため、手作業でサンプルを採取しています。統計的な精度で時間を知ることは、それほど重要ではありません。

  • 複数の問題を見つけて修正することの重要性はいくら強調してもしすぎることはありません。速度の問題はいくつか発生し、修正するたびに、既に解決された問題に乗数効果が生じます。見つからないものは、制限要因になります。

  • 非同期のスレッド間メッセージ パッシングが多く含まれるプログラムは、より困難になります。なぜなら、ある瞬間が費やされている完全な理由を識別するのが難しくなるためです。

それについてもっと。

于 2013-04-16T11:44:00.510 に答える