Callgrindを使用したCFDコードのプロファイリング

Valgrind + Callgrindを使用して、作成したソルバーのプロファイルを作成しています。Valgrindユーザーマニュアルに記載されているように、コンパイラーのデバッグオプションを使用してコードをコンパイルしました。

「デバッグ情報がなければ、Valgrindの最良のツールは、特定のコードがどの機能に属するかを推測するため、エラーメッセージとプロファイリング出力の両方がほとんど役に立たなくなります。-gを使用すると、関連するソースコード行。」

Valgrindマニュアル

デバッグオプションを使用してコンパイルすると、コードの実行速度が大幅に低下します。CFDコードは、デバッグフラグを付けてコンパイルした場合でも、非常に遅くなります。Valgrindを使用すると、40倍遅くなります（マニュアル1を参照）。

1. コードプロファイリング（ベンチマークではなくプロファイリング）にどのツールを使用していますか？

2. コードを実行する時間（統計：時間ステップ数）。

3. ケースの大きさ（ケースがキャッシュに収まる場合、ソルバーは桁違いに高速ですが、メモリ関連のプロセスを見逃すことになります）

Q1：コードプロファイリング（ベンチマークではなくプロファイリング）にどのツールを使用していますか？

Q2：コードを実行する時間（統計：時間ステップ数）。

Q3：ケースの大きさ（ケースがキャッシュに収まる場合、ソルバーは桁違いに速くなりますが、メモリ関連のプロセスを見逃します）？

ここに私がそれをする方法の例があります。

ベンチマーク（所要時間を確認）とプロファイリング（高速化の方法を特定）を分離します。プロファイラーが高速であることは重要ではありません。何を修正するかを伝えることが重要です。

私は「プロファイリング」という言葉すら好きではありません。なぜなら、それは各ルーチンのコストバーがあるヒストグラムのようなイメージを想起させるからです。修繕。これらの両方は、何らかのタイミングと統計を意味します。そのためには、精度が重要であると想定しています。タイミングの正確性に関する洞察を放棄する価値はありません。

私が使用する方法はランダムに一時停止する方法であり、ここに完全なケーススタディとスライドショーがあります。プロファイラーのボトルネックの世界観の一部は、何も見つからない場合は何も見つからないことであり、何かを見つけて一定の速度向上が得られる場合は、勝利を宣言して終了します。プロファイラーのファンは、彼らがどれだけスピードアップするかについてはほとんど言いません。広告には、見つけやすいように意図的に作られた問題のみが表示されます。ランダムに一時停止すると、問題が簡単であろうとなかろうと、問題が見つかります。次に、1つの問題を修正すると他の問題が公開されるため、プロセスを繰り返して複合的な高速化を実現できます。

多数の例からの私の経験では、その方法は次のとおりです。1つの問題を（ランダムに一時停止することで）見つけて修正し、数パーセント、たとえば30％または1.3倍のスピードアップを得ることができます。それからもう一度やり直して、別の問題を見つけて修正し、別のスピードアップを得ることができます。30％未満かもしれません。その後、本当に他に修正するものが見つからなくなるまで、何度もそれを行うことができます。究極のスピードアップ要因は、個々の要因の実行中の積であり、驚くほど大きくなる場合があります-場合によっては桁違いに大きくなります。

挿入：この最後のポイントを説明するためだけに。ここには、スライドショーとすべてのファイルを含む詳細な例があり、一連の問題の除去で730xの高速化がどのように達成されたかが示されています。最初のバージョンでは、作業単位あたり2700マイクロ秒かかりました。問題Aは削除され、時間が1800に短縮され、残りの問題の割合が1.5倍（2700/1800）に拡大されました。その後、Bが削除されました。このプロセスは6回繰り返され、ほぼ3桁のスピードアップが実現しました。しかし、プロファイリング手法は本当に有効でなければなりません。これらの問題のいずれかが見つからない場合、つまり、これ以上何もできないと誤って考えるポイントに達すると、プロセスが停止するからです。

挿入済み：別の言い方をすれば、次の問題は連続した問題が取り除かれたときの全体的なスピードアップ係数のグラフです：

そのため、Q1では、単純なタイマーのベンチマークで十分です。「プロファイリング」では、ランダムな一時停止を使用します。

Q2：一時停止するのに十分な時間実行されるように、十分なワークロードを与えます（または単にループをループします）。

Q3：どうしても、キャッシュの問題を見逃さないように、現実的に大きなワークロードを与えてください。これらは、メモリフェッチを行うコードのサンプルとして表示されます。

貧乏人のプロファイラは、基本的にはgdbスクリプトのサンプルそのコールスタック。それでもデバッグシンボルが必要です。それでも遅いですが、コードを実行する仮想マシンを実装していないため、多くの場合よりも高速ですcallgrind、タスク適切です。

素粒子物理学アナライザーを少し使って成功しました（つまり、コードには恐ろしいホットスポットがなく、最適化にはより良いアルゴリズムが必要であることを示しました）。

利用可能な優れた答えに追加するために、スタックサンプリングを自動化するオーバーヘッドがほとんどないライスで開発されたツールがあります。

http://hpctoolkit.org/

Allinea MAPは、商業的に開発およびサポートされているサンプリングプロファイラーであるため、以前の回答で提案されたHPC Toolkitのように、必要に応じて実稼働サイズのジョブで実行できます。

この種のツールは、CPUのボトルネックまたはMPIの不十分な通信を示しますが、ジョブ全体のプロファイリングの全体的な監視は、驚きの問題を見つけるのに貴重な場合があります。

多くの場合、CFDコードのコアカーネルの外側にある、予想外の領域で、パフォーマンスが低く維持されることがあります。ランダム化されたスタックサンプリングは、GDBを使用して手動で実行する場合でも、HPC ToolkitやAllinea MAPなどのツールを使用して実行する場合でも、それらを見つける最良の方法です。パフォーマンスにとって重要なものがある場合、それが表示されます。