MPI_Iprobe对MPI_Probe

Question

在MPI_Iprobe中，需要多次检查标志以确定是否存在任何消息，其中一种方法是将其放入way循环中，我想知道这种方法是否等同于MPI_Probe，因为它基本上以不同的方式阻止探测，这是使用I探针的错误方式吗？

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_Probe而不是MPI_Iprobe-loop。使用MPI_Wait而不是MPI_Test-loop。尽可能使用集体而不是单个的点对点消息。

如果希望将通信与计算重叠，同步MPI_I...函数通常很有用，但不应使用它们重新实现现有的MPI功能。

通过使用MPI_Probe，您可以为实现提供优化和调优的自由。一方面，MPI可以阻塞，直到消息出现，从而节省CPU周期/电源。另一方面，它可以有一个较低的延迟，因为没有浪费时间进入MPI堆栈一次又一次。对于使用PMPI层的任何工具来说，使用一个MPI_Probe调用而不是数千个MPI_Iprobe调用也更好。在实际的HPC应用程序中，我仅通过将MPI_Test-loop替换为MPI_Waitany就实现了10%以上的加速。

唯一的例外是，如果您已经用尽MPI实现的调优选项，并且可以肯定地显示您自己的轮毂重新实现比MPI提供的复合操作更好。

MPI_Irecv调用也相当奇怪。您是否有充分的理由使用异步接收，尽管您知道已经有一个挂起的消息？为什么不发布MPI_Irecv，而不是从一开始就进行探测？如果您知道分配接收缓冲区所需的最大大小，还可以在MPI_ANY_SOURCE上发布一个接收计数大于发送计数的MPI_ANY_SOURCE。