MPI_Bcast或MPI_Send的探测 [英] Probe for MPI_Bcast or MPI_Send

问题描述

我有一个程序，其中有一个主站/从站设置，并且我为主站实现了一些功能，这些功能将不同种类的数据发送到从站.某些功能发送给各个从站，而某些功能则通过MPI_Bcast向所有从站广播信息.

I have a program where there is a master/slave setup, and I have some functions implemented for the master which sends different kinds of data to the slaves. Some functions send to individual slaves, but some broadcast information to all the slaves via MPI_Bcast.

我希望在从站中只有一个接收功能，所以我想知道我是否可以探测一条消息，并知道它是作为普通的阻止消息广播还是发送，因为有不同的方法来接收消息广播和正常发送的内容.

I want to have only one receive function in the slaves, so I want to know if I can probe for a message and know if it was broadcasted or sent as a normal blocking message, since there are different method to receive what was broadcasted and what was sent normally.

推荐答案

不，您不能基于探测调用来决定是调用Bcast还是Recv.

No, you can't decide whether to call Bcast or Recv on the basis of a probe call.

MPI_Bcast调用是一个集体操作-所有MPI任务都必须参与.结果，这些不像点对点通信.他们利用所有过程都涉及到的事实来进行高阶优化.

A MPI_Bcast call is a collective operation -- all MPI tasks must participate. As a result, these are not like point to point communication; they make use of the fact that all processes are involved to make higher-order optimizations.

因为集体操作意味着太多的同步，所以让其他任务检查是否应该开始参与集体就没有意义了.这是必须包含在程序逻辑中的东西.

Because the collective operations imply so much synchronization, it just doesn't make sense to allow other tasks to check to see whether they should start participating in a collective; it's something which has to be built into the logic of a program.

• 广播中的根进程的角色不同于发送.通常，它不能只调用MPI_Bcast然后继续.几乎可以肯定，直到其他一些进程参与了广播之后，该实现才会阻塞.和

• The root process' role in a broadcast is not like a Send; it can't, in general, just call MPI_Bcast and then proceed. The implementation will almost certainly block until some other number of processes have participated in the broadcast; and

广播中的另一个进程的角色不像接收消息.通常，它将同时接收和发送信息.因此，参与广播与进行简单的Recv通话不同.

The other process' role in a broadcast is not like receiving a message; in general it will be both receiving and sending information. So participating in a broadcast is different from making a simple Recv call.

因此Probe无法正常工作； MPI_Probe的文档很清楚，它返回信息关于下一个MPI_Recv会发生什么，Recv是与Bcast不同的操作.

So Probe won't work; the documentation for MPI_Probe is fairly clear that it returns information about what would happen upon the next MPI_Recv, and Recv is a different operation than Bcast.

您可能能够在MPI 3.0中获得一些所需的功能，该功能目前正在最终确定中，它允许无阻塞的集合(例如MPI_Ibcast).在这种情况下，您可以启动广播并调用MPI_Test来检查请求的状态.但是，即使在这里，每个人都需要首先调用MPI_Ibcast.这只会使集体通信和点对点通信更容易交织.

You may be able to get some of what you want in MPI 3.0, which is being finalized now, which allows for nonblocking collectives -- eg, MPI_Ibcast. In that case you could start the Broadcast and call MPI_Test to check on the status of the request. However, even here, everyone would need to call the MPI_Ibcast first; this just allows easier interleaving of collective and point-to-point communication.

这篇关于MPI_Bcast或MPI_Send的探测的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！