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