在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);
}
Run Code Online (Sandbox Code Playgroud)
是的,基本上MPI_Iprobe像你建议的循环具有相同的语义MPI_Probe.但是,您通常应该更喜欢复合操作,而不是自己实现它.所以使用MPI_Probe而不是MPI_Iprobe-loop.使用MPI_Wait而不是MPI_Test-loop.尽可能使用集合而不是单独的点对点消息.
MPI_I...如果要将通信与计算重叠,则同步函数通常很有用,但不应使用它们来重新实现现有的MPI功能.
通过使用,MPI_Probe您可以为实现提供优化和调优的自由.一方面,MPI可以阻塞,直到出现消息,从而节省CPU周期/功率.另一方面,它可以具有较低的延迟,因为没有浪费时间一次又一次地进入MPI堆栈.使用PMPI层使用一个MPI_Probe呼叫而不是数千个MPI_Iprobe呼叫的任何工具也更好.仅仅通过替换MPI_Test-loop,我在现实世界的HPC应用程序中实现了> 10%的加速MPI_Waitany.
唯一的例外是,如果您已经用尽了MPI实现的调整选项,并且可以肯定地表明您自己的轮重新实现比MPI提供的复合操作更好.
这个MPI_Irecv电话也很奇怪.尽管知道已经有待处理的消息,您是否有充分的理由使用异步接收?为什么不首先发布MPI_Irecv而不是探测?如果您知道分配接收缓冲区所需的最大大小,则还可以使用大于发送计数的接收计数发布MPI_Irecvon MPI_ANY_SOURCE.