MPI_IprobeとMPI_Probeとの比較

Question

MPI_Iprobeでは、何らかのメッセージがあるかどうかを調べるためにフラグを数回確認する必要があります。これを行うにはwhileループに入れる方法があります。 MPI_Probe 基本的にプロービングを別の方法でブロックするので、 これはIprobeを使用する間違った方法ですか？

int flag=0 
while(flag==0) 
{ 
MPI_Iprobe(MPI_ANY_SOURCE, MPI_ANY_TAG, MPI_COMM_WORLD, &flag,&status); 
cout<<myrank<<" "<<flag<<endl; 
} 
if(flag) 
{ 
MPI_Get_count(&status, MPI_INT, &count); 

MPI_Irecv(&rcvbuff,count, MPI_INT,destination.at(0),0, MPI_COMM_WORLD, &request); 

} 

Answer 1

はい、あなたがお勧めのようMPI_Iprobe周りの基本的ループがMPI_Probeとしてセマンティックと同じです。しかし、通常は、自分でに実装するのではなく、複合操作を優先する必要があります。したがって、MPI_Iprobe -loopの代わりにMPI_Probeを使用してください。 MPI_Test -loopの代わりにMPI_Waitを使用してください。可能であれば、個々のポイントツーポイントメッセージの代わりにcollectivesを使用してください。

同期のMPI_I...関数は、計算との通信を重複させたい場合には一般的に便利ですが、既存のMPI機能を再実装するために使用しないでください。

MPI_Probeを使用すると、実装に最適化とチューニングの自由を与えることができます。一方で、MPIはメッセージが来るまでブロックし、CPUサイクル/電力を節約することができます。一方、MPIスタックに何度も何度も浪費する時間が無駄にならないので、待ち時間が短くなる可能性があります。また、PMPIレイヤーを使用してMPI_Iprobeコールの代わりにMPI_Probeコールを使用するツールには、さらに優れています。私はMPI_Test -loopをMPI_Waitanyに置き換えるだけで、現実のHPCアプリケーションで> 10％のスピードアップを達成しました。

唯一の例外は、MPIインプリメンテーションのチューニングオプションを使い果たし、ホイールの独自の再実装がMPIによって提供される複合操作よりも優れていることを明確に示すことができます。

MPI_Irecvコールもかなり奇妙です。すでに保留中のメッセージがあることを知っているにもかかわらず、非同期受信を使用する良い理由はありますか？最初にプロービングする代わりにMPI_Irecvを投稿するのはなぜですか？受信バッファの割り当てに必要な最大サイズがわかっている場合は、MPI_IrecvをMPI_ANY_SOURCEに送信し、受信カウントを送信カウントより大きくすることもできます。