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


16

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

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

Valgrindマニュアル

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

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

  2. コードを実行する時間(統計:時間ステップ数)。

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


3
デバッグシンボルと最適化の両方を有効にしてコードをコンパイルできます。それでも、40xからvalgrind(すべてのメモリアクセスをシミュレート)は不合理ではありません。
アロンアフマディア

おかげで、これも私が読んだものです...私が知りたいのは、プロファイリングの毎日の経験に関する情報です(できればvalgrindを使用して):レポートを待つのにどれくらいの時間が通常か、繰り返しの数カウント、私は何を除外することができます...など
...-tmaric

あなたの質問も少し広範です。Q1はまったく異なる質問なので、Q2.1とQ2.2に焦点を合わせて質問を編集することをお勧めします(個別に質問できてうれしいです。良い質問ですが、「どのツールを使いますか? Xがよく記述されている問題X "を解決するために使用してください!)、Q2自体は一般的すぎます。
アロンアーマディア

あなたも名前を編集することができcallgrindcachegrindまたはmassif。多くの人がValgrindをデフォルトのツール(memcheck)にのみ関連付けています。(割り込みベースではなく)エミュレーションベースのプロファイリングシステムとして、長時間実行する必要はありません。
ジェドブラウン

@Aron&Jed:ヒントをありがとう、質問を編集しました。:)
tmaric

回答:


11

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

Q2:コードを実行する時間(統計:時間ステップ数)。

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

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

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

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

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

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

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

複数の問題を除去して大幅な高速化を実現する説明

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

ここに画像の説明を入力してください

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

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

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


マイク、ビジュアルIDEがないときにランダムに一時停止する方法を好みますか?このプロセスは何らかの方法で自動化できますか?
マシューエメット

@Matthew:pstackやのようなツールがあることは理解していますが、lsstackこれはデバッグと共通のプロセスだと本当に思っています。だから、私が持ってくることができる最高のデバッガーがであったとしてもgdb、それは仕事を終わらせます。デバッガを使用すると、データを調べることができ、スタックだけでは十分ではない場合に違いを生むことができます。
マイクダンラベイ

9

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

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


1
+証拠の不在は不在の証拠ではありません:)貧乏人のプロファイラーがすべきことは、痕跡を少なくしてそれらを崩壊させないことですが、それらを見せてください。人間の目は、単純な関数時間の推定よりも有用なパターンの検出がはるかに優れており、わずか2サンプルで改善できるものがあれば、それは非常に役立ちます。保存する割合Xは、モード2 / Nのベータ分布です。ここで、Nは検査したトレースの数であり、高速化係数は1 /(1-X)であり、大きくなる可能性があります。
マイクダンラベイ

2

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

http://hpctoolkit.org/


それはいいように見えますが、(申し訳ありませんが)私はここに私の炎の帽子をかぶっています。マングルされたコードで何が起こっているかを見るのは難しいので、コンパイラー向けに最適化されたコードはチューニングしません。プルーニングしているものは、オプティマイザーが処理できるものではありません- 同じ引数を繰り返し呼び出しexpたりlog、オプションのデコードにすべての時間を費やしている行列演算のように。できる限りチューニングしてから、-O3をオンにします。
マイクダンラベイ

ツールはツールであり、ユーザーが制限を知って理解している場合にのみ役立ちます。その出力を理解し、情報の使用方法を知ることに関して、ユーザーを方程式から完全に削除する「完璧なプロファイラー」が存在するとは思いません。
Reid.Atcheson

1

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

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

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.