我正在编写一个多线程OpenMPI应用程序，使用来自多个线程的MPI_Isend和MPI_Irecv在InfiniBand RDMA的各个列之间每秒交换数百条消息。
传输量约为400-800KByte，每个等级产生约9 Gbps的输入和输出，完全在FDR的容量之内。简单的MPI基准测试也显示出良好的性能。
通过在专用线程中使用MPI_Testsome轮询所有事件的传输来检查传输是否完成。
我达到的传输速率取决于消息速率，但更重要的是，还取决于MPI_Testsome的轮询频率。也就是说，如果我每10ms轮询一次，则请求的完成要比我每1ms轮询一次完成。
我希望如果我每10毫秒而不是每1毫秒轮询一次，那么最多9毫秒后我就会收到完成请求的通知。我不希望传输本身通过减少对MPI_Testsome的调用而延迟完成，从而不会降低总传输速率。我希望MPI_Testsome完全是被动的。
这里有人知道为什么会发生这种现象吗？
最佳答案
观察到的行为是由于在Open MPI中实现操作进度的方式引起的。发布发送或接收消息，无论是同步还是异步完成，都会导致一系列内部操作排队。进度基本上是对那些排队的操作的处理。在库构建时，可以选择两种模式:一种具有异步进度线程，而另一种则不带默认线程。
在启用异步进度线程的情况下编译库时，后台线程会处理并处理队列。这允许后台传输与用户代码并行开始，但会增加延迟。如果没有异步进行，则操作会更快，但是仅当用户代码调用MPI库时，才会发生进行。而在MPI_Wait或MPI_Test和家庭中。 MPI_Test系列函数的实现方式是尽可能快地返回。这意味着库必须在调用过程中权衡取舍，从而减慢它的运行速度或快速返回，这意味着每次调用都进行较少的操作。
一些Open MPI开发人员，特别是Jeff Squyres，时不时地访问Stack Overflow。他可能会提供更多细节。
此行为几乎不特定于Open MPI。除非有大量的硬件辅助，否则MPI通常是按照相同的方法实现的。
关于multithreading - InfiniBand:传输速率取决于MPI_Test *频率，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22038918/