MPI星（hub-and-spoke）通信器的性能是否优于MPI_COMM_WORLD？

Question

让我们考虑以下MPI应用程序的简单场景：根进程广播（MPI_Bcast）一些参数（几十个字节 - 固定大小），然后所有节点开始执行一些计算，然后根收集结果（MPI_Gather - 可能是非常大的数据集）。在根保存数据之后，程序结束。

在什么情况下（进程数，延迟等）（如果有的话）使用使用虚拟星形拓扑创建的通信器会比使用MPI_COMM_WORLD提供更好的性能，为什么？通信器是否对实际通道使用延迟初始化（即，仅在第一次需要时打开管道，插座等）。此行为实现是否依赖？

注意：我正在使用openmpi1.4.3-2和普通C。

Answer 1

Communicator拓扑是便捷映射功能，不需要它们来改变实际通信的发生方式。即使在星形或任何其他图形拓扑中存在未连接的进程（在拓扑意义上），如果它们知道通信器中的其他进程的等级，则这不会阻止它们彼此发送消息。 。 MPI实现可能会使用拓扑作为提示来优化通信路径，但这会使它们成为非常复杂的代码片段，并且至少Open MPI不会在其集合算法中执行此操作（测试不是很好，因此通常禁用hierarch集合组件考虑硬件层次结构，但不考虑虚拟拓扑结构。）

如果向通信器构造函数提供reorder=1，拓扑可能会通过排名重新排序来影响通信。这使得MPI实现可以自由地重新排序进程级别，以便在给定下面硬件的物理拓扑的情况下尽可能接近地将它们的物理位置匹配到提供给构造函数的拓扑方案。存在具有用于集体操作的专用网络的硬件平台。例如，IBM Blue Gene / P有一个全局中断网络，允许快速实现MPI_BARRIER和一个专门的集体网络，加速一些集体操作（包括广播）。但这些仅适用于MPI_COMM_WORLD - 后备软件实现用于任何其他通信器。

  

此行为实现是否依赖？

是的，它是依赖于系统的实现和（适用于支持多个硬件/通信系统的实现）。这也是你提出的其他问题的答案。