什么可能导致 MPI 非阻塞消息的吞吐量不对称？
我正在使用 MPI 非阻塞消息在两个任务之间进行通信。通信模式如下：每个任务都有一个主线程，用于接收来自其他任务的消息。它有 5 个左右的工作线程，用于执行计算并向其他任务发送消息。主线程循环，测试传入消息。这是它唯一做的事情。
我的问题是，虽然任务 0 立即接收到从任务 1 发送的所有消息（发送和接收的消息数量大致匹配），但任务 1 只接收到任务 0 发送的大约 1/4 消息。运行一分钟后，有数百条消息数以千计的未完成消息。
使用 PAPI，我确定任务 1 似乎在 test 和 irecv 上被阻止。指令吞吐量仅为 0.03 指令/周期，而其他任务则大于 0.2，并且在调试器中停止该任务表明它正在尝试获取锁。然而，阻塞的接收和测试不是“丢失”消息的接收和测试，而是另一类更罕见的消息。
我意识到，如果不实际尝试代码，很难说是什么原因导致了这种情况，但我发现 MPI 性能存在如此不对称性，这令人费解。无法跟上接收的任务并不是因为缺乏尝试，而是实际上花费了所有时间来测试传入的消息。
我使用带有 MPI_THREAD_MULTIPLE 的 OpenMPI 1.5.3，并且通过 sm 进行通信（两个任务位于同一节点上）。
任何如何追踪这一点的想法将不胜感激。
I'm using MPI nonblocking messages to communicate between 2 tasks. The communication pattern is as follows: Each task has a master thread that receives messages from the other tasks. It has 5 or so work threads that do a computation and send messages to the other tasks. The master thread loops, testing for incoming messages. This is the only thing it does.
My problem is that while task 0 instantaneously receives everything sent from task 1 (number of messages sent and received roughly match), task 1 only receives about 1/4 of the messages sent by task 0. After running for a minute, there are hundreds of thousands of outstanding messages.
Using PAPI, I've determined that task 1 seems to block on test and irecv. The instruction throughput is only 0.03 instr/cycle as opposed to >0.2 for the other task, and stopping the task in the debugger shows that it is trying to acquire a lock. However, the receive and test that is blocking is not the ones for the "missing" messages but for another class of much rarer messages.
I realize it's hard to say what could cause this without actually trying the code, but I find it puzzling that there is such an asymmetry in the MPI performance. The task that can't keep up with the receives is not for lack of trying, it's really spending all its time testing for incoming messages.
I'm using OpenMPI 1.5.3 with MPI_THREAD_MULTIPLE, and the communication is over sm, (the two tasks are on the same node).
Any ideas how to track this down would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论