何时不使用 MPI答案

【问题标题】：When not to use MPI何时不使用 MPI
【发布时间】：2011-11-23 05:41:44
【问题描述】：

这不是关于 MPI 的特定技术编码方面的问题。我是 MPI 的新手，不想以错误的方式使用库而自欺欺人，因此在此处发布问题。

据我了解，MPI 是一种在分布式内存模型上构建并行应用程序的环境。

我有一个与 Infiniband 互连的系统，其唯一目的是执行一些非常耗时的操作。我已经破解了并行执行的算法，所以我实际上只是使用 MPI 在 Infiniband 上的多个节点之间传输数据（中间步骤的结果），我相信可以简单地使用 OpenIB 来完成。

我是否以正确的方式使用 MPI？还是我歪曲了系统的初衷？

【问题讨论】：

是的，这正是 MPI 的设计目的。

标签： parallel-processing mpi hpc

【解决方案1】：

在您的算法中只使用 MPI_Send 和 MPI_Recv 很好。随着算法的发展，您会获得更多经验等。您可能会发现更“高级”的 MPI 功能（例如 Gather、Reduce 等障碍和集体通信）有用。

【讨论】：

Send-Recv 是低级原语。您应该渴望首先使用集体，因为它们更容易推理。人们使用 Send-Recv 的许多常见模式现在可以在 MPI-3 的邻域集合中表达。

【解决方案2】：

完成工作所需使用的 MPI 结构越少越简单，更好 MPI 就可以解决您的问题——您可以说，对于大多数库和语言，作为实际问题，可以说是抽象问题。

是的，您也可以编写原始 OpenIB 调用来完成您的工作，但是当您需要迁移到以太网集群、大型共享内存机器或下一个大型互连设备时会发生什么？ MPI 是中间件，因此，它的一大卖点是您不必花时间编写网络级代码。

【讨论】：

+1 不知道否决票，说得好，说得通！
它回答了我的问题，我想我同意你的观点，使用 MPI 确实使我能够抽象出底层的通信机制，因此更具可扩展性（当然在 MPI 的范围内）。
我不同意您应该使用尽可能少的 MPI 结构。您应该使用正确的结构——不多也不少。
@Jeff 谁说你不同意的那件事？
@JonathanDursi 我在回复“完成工作所需使用的 MPI 结构越少越简单，MPI 越能解决你的问题……”也许你不是主张使用尽可能少的 MPI 结构，但似乎是这样。

【解决方案3】：

在复杂性范围的另一端，不使用 MPI 的时候是当您的问题或解决方案技术表现出足够的活力，以至于 MPI 的使用（尤其是其流程模型）成为一个障碍时。像Charm++ 这样的系统（披露：我是 Charm++ 的开发人员）可以让您根据更细粒度的单元进行问题分解，其运行时系统管理这些单元到处理器的分配以确保负载平衡，并跟踪他们将在哪里适当地指导沟通。

另一个不常见的问题是动态数据访问模式，其中像全局数组或 PGAS 语言这样的东西更容易编码。

【讨论】：

您说的是 MPI 的使用，而不是 MPI 是什么。 Charm++ 可以位于 MPI 之上，这证明 MPI 适用于动态计算 - 只需实现动态性或从 Charm++ 等中间件获取。
Charm++ 可以位于 MPI 之上，但这不是首选的网络后端。两者只是不同 - 例如，“无论具体的实现细节如何，我们认为 MPI 的预期消息性质和 Charm++ 的意外消息行为之间存在根本差异。这种差异使得前者不太适合执行通信后者的职责。", Gunter et al
您可能希望在 Google Scholar 上查看“通过 MPI 优化 Charm++”。通过为 Charm++ 使用模型调整 MPI 可以显着提高性能，其中大多数（所有？）消息都是意外的。