MPI Isend/Irecvパフォーマンスの振る舞い

Question

という名前のルーチンがMPIルーチンを呼び出すtransfer（int）という名前のルーチンを持っています。私のメインプログラムでは、transfer（）が2回呼び出されます。

... // do some work 
transfer(1); // first transfer 
... // do some work again 
transfer(2); // second transfer 

---

転送（int型）機能は、私が唯一の前処理を除いて、通信時間を測定し、この

... // do some work 
MPI_Barrier(MPI_COMM_WORLD); 
t0 = clock(); 
for(int k=0; k<mpisize; k++) { 
    MPI_Irecv((void*)rbuffer[k], rsize[k], MPI_BYTE, k, 0, MPI_COMM_WORLD, reqs+2*k); 
    MPI_Isend((void*)sbuffer[k], ssize[k], MPI_BYTE, k, 0, MPI_COMM_WORLD, reqs+2*k+1); 
} 
MPI_Waitall(2*mpisize, reqs, status); 
MPI_Barrier(MPI_COMM_WORLD); 
if (mpirank==0) cerr << "Transfer took "<< (double)(clock()-t0)/CLOCKS_PER_SEC << " secs" << endl; 

ノートのように見えます。 転送（1）について

---

、すべての送信およびバッファは各Kためにサイズ0を有する受け取ります。本質的に、コミュニケーションは起こっていません。しかし、転送は1.95秒かかった。

転送（2）の場合、各プロセッサは他のすべてのプロセッサと約20KBを送受信する必要があります。しかし、全体の転送は0.07秒しかかかりませんでした。

私はこの実験を1024プロセッサで何度も実行しました。測定値は一貫しています。この現象や何が間違っているのか説明できますか？

ありがとうございました。

Answer 1

方が良い何が起こっているかを理解するために、このようなVampirやScalascaとしてMPIパフォーマンス解析ツールを使用することができます。

• が遅いか、わずか数残りはバリアで待機しているすべての通信はありますか？
• 障壁の影響は何ですか？

実際の回答は、システムとMPIの実装に大きく依存します。ゼロサイズのメッセージには依然として通信が必要であり、最初の通信で追加のオーバーヘッドが発生する可能性があるというAnycornのコメントは、調査を開始するのに適しています。あなたが答えようとするべき別の質問は次のとおりです。

• 2番目のゼロサイズのメッセージはどのようにふるまいますか？

また、MPI実装は、基本的に異なるサイズのメッセージを処理できます。予期せぬメッセージバッファーを使用することによって実現されますが、これも実装およびシステムに依存します。