コンパイルして実行する MPI プログラムを持っていますが、異常が発生していないことを確認するためにステップ実行したいと考えています。理想的には、GDB を特定のプロセスにアタッチする簡単な方法が欲しいのですが、それが可能かどうか、またはその方法がよくわかりません。別の方法として、各プロセスでデバッグ出力を個別のログ ファイルに書き込むこともできますが、これでは実際にはデバッガと同じ自由度は得られません。
より良いアプローチはありますか?MPI プログラムをどのようにデバッグしますか?
gdb は非常に便利であることがわかりました。私はそれを
mpirun -np <NP> xterm -e gdb ./program
これにより、実行できるxtermウィンドウが起動します
run <arg1> <arg2> ... <argN>
通常は正常に動作します
以下を使用して、これらのコマンドを一緒にパッケージ化することもできます。
mpirun -n <NP> xterm -hold -e gdb -ex run --args ./program [arg1] [arg2] [...]
ここでの投稿の多くは GDB に関するものですが、起動からプロセスにアタッチする方法については触れていません。明らかに、すべてのプロセスにアタッチできます。
mpiexec -n X gdb ./a.out
しかし、すべてのプロセスを開始するために跳ね返らなければならないため、これは非常に効果的ではありません。1 つ (または少数) の MPI プロセスをデバッグするだけの場合は、次の:
演算子を使用して、コマンド ラインで別の実行可能ファイルとして追加できます。
mpiexec -n 1 gdb ./a.out : -n X-1 ./a.out
これで、プロセスの 1 つだけが GDB を取得します。
他の人が述べたように、少数の MPI プロセスのみを使用している場合は、複数の gdb セッション、信頼できるvalgrindを使用するか、独自の printf/logging ソリューションをロールすることができます。
それよりも多くのプロセスを使用している場合は、適切なデバッガーが本当に必要になります。OpenMPI FAQでは、 Allinea DDTとTotalViewの両方を推奨しています。
私はAllinea DDTに取り組んでいます。これはフル機能のグラフィカルなソースコード デバッガーなので、次のことができます。
...等々。Eclipse または Visual Studio を使用したことがある場合は、すぐに慣れることができます。
並列コード (MPI、マルチスレッド、CUDA など)のデバッグに特化したいくつかの興味深い機能を追加しました。
スカラー変数はすべてのプロセスで自動的に比較されます:
(ソース: allinea.com )
プロセスと時間にわたって変数と式の値を追跡およびフィルタリングすることもできます。
ORNL、NCSA、LLNL、Jülichなどの上位 500 の HPC サイトで広く使用されています。アル。
インターフェースはかなりきびきびしています。Oak Ridge の Jaguar クラスタでの受け入れテストの一環として、220,000 プロセスのスタックと変数のステッピングとマージの時間を 0.1 秒で測定しました。
@tgamblin は、他のいくつかの人気のあるオープン ソース プロジェクトと同様に、Allinea DDTと統合された優れたSTATについて言及しました。
並列プログラミングを支援することを目的とした私のオープンソース ツール padb もあります。デバッガーとして機能するだけでなく、たとえば並列トップのようなプログラムとしても機能するため、「ジョブ検査ツール」と呼んでいます。「フル レポート」モードで実行すると、アプリケーション内のすべてのプロセスのスタック トレースと、すべてのランクのすべての関数のローカル変数が表示されます (-g でコンパイルした場合)。また、ジョブ内の各ランクの未処理の送受信のリストである「MPI メッセージ キュー」も表示されます。
完全なレポートを表示するだけでなく、ジョブ内の個々の情報を拡大するように padb に指示することもできます。表示される情報を制御するための無数のオプションと構成項目があります。詳細については、Web ページを参照してください。
MPI プログラムをデバッグする「標準的な」方法は、その実行モデルをサポートするデバッガーを使用することです。
UNIX では、TotalViewは MPI を適切にサポートしていると言われています。
MPI プログラムをデバッグする非常に簡単な方法。
main () 関数に sleep (some_seconds) を追加
通常どおりプログラムを実行します
$ mpirun -np <num_of_proc> <prog> <prog_args>
プログラムが起動し、スリープ状態になります。
したがって、ps でプロセスを見つけ、gdb を実行してそれらにアタッチするのに数秒かかります。
QtCreator などのエディターを使用する場合は、使用できます
デバッグ -> デバッグを開始 -> 実行中のアプリケーションにアタッチ
そこでプロセスを見つけます。
mpirun -gdb
http://www.ncsa.illinois.edu/UserInfo/Resources/Hardware/CommonDoc/mpich2_gdb.html(アーカイブリンク)に感謝します
ログ トレースを使用して MPI 関連のデバッグを行いますが、mpich2 を使用している場合は gdb を実行することもできます: MPICH2 および gdb。この手法は、デバッガーから起動するのが難しいプロセスを扱う場合に一般的に有効な方法です。
もう 1 つの解決策は、シミュレートされた MPI である SMPI 内でコードを実行することです。これは、私が関与しているオープン ソース プロジェクトです。すべての MPI ランクは、同じ UNIX プロセスのスレッドに変換されます。その後、gdb を使用して MPI ランクを簡単にステップアップできます。
SMPI は、MPI アプリケーションの研究に他の利点を提案します: 千里眼 (システムのすべての部分を観察できます)、再現性 (指定しない限り、数回の実行でまったく同じ動作が得られます)、ハイゼンバグの欠如 (シミュレートされたプラットフォームが異なるため)ホストから)など。
詳細については、このプレゼンテーションまたは関連する回答を参照してください。