MPICH与OpenMPI的比较

Question

MPICH与OpenMPI的比较

mpihpcopenmpi

161

有人可以详细说明OpenMPI和MPICH实现MPI的区别吗？这两者哪个实现更好？

- lava

2

请参阅：https://dev59.com/vnVC5IYBdhLWcg3w7Vxq - Taylor Leese

2

我们个人选择了OpenMPI作为我们的MPI实现。对我们来说，它的基准测试效果更好，可移植性不是那么重要。请参见Taylor L发布的问题链接。 - Xorlev

1

您还可以考虑在Google趋势中，OpenMPI的搜索量比MPICH/MPICH2高2-3倍。 - Foad S. Farimani

我认为MPICH在最近的Linux版本中不再受支持（例如，Ubuntu 18无法运行它），如果我没记错的话，它只能在某些内核版本中工作。 - jrh

@jrh mpich 可以轻松地从源代码编译。 - Victor Eijkhout

5个回答

18

如果您需要进行开发而不是生产系统，请使用MPICH。 MPICH具有内置的调试器，而Open-MPI在我上次检查时没有。

在生产中，Open-MPI很可能会更快。但是您可能希望研究其他替代方案，例如Intel MPI。

- Anycorn

5

我不确定您所说的“built-in debugger”是指什么，但我发现Open-MPI与例如gdb的集成非常好：https://www.open-mpi.org/faq/?category=debugging。 - Jeff Hammond

生产环境中，是否考虑使用MPICH和TAO？ - namu

内置调试器是什么？我该如何使用它？ - Nanashi No Gombe

12

我同意之前的评论者。尝试两个选项，看看哪个应用程序运行更快，然后将其用于生产。它们都符合标准。如果是你的桌面电脑，两个都可以。OpenMPI在Macbooks上使用很方便，而MPICH似乎更适合Linux/Valgrind环境。这取决于你自己和你的工具链。

如果是生产集群，您需要进行更广泛的基准测试，以确保它针对您的网络拓扑进行了优化。在生产集群上配置它将是你的时间成本主要区别，因为你将不得不阅读文档。

- Chad Brewbaker

16

如果每个人都仔细阅读了文档，我们就不需要 StackOverflow :-) - Jeff Hammond

1

顺便提一下，Open-MPI在Valgrind清洁方面有一个常见问题解答条目：https://www.open-mpi.org/faq/?category=debugging#valgrind_clean - Jeff Hammond

@Jeff 那关于 bug 呢？过时的文档呢？这是我在这里提出的大多数问题的原因 ;) - WestCoastProjects

1

@JeffHammond 如果有人一直已经阅读了文档，那肯定就是解决方案了！ - William Gallafent

9

两者都符合标准，所以从正确性的角度来看，使用哪个都无所谓。除非有一些特定的调试扩展等功能是必须的，否则建议对两者进行基准测试，并选择在你的硬件上应用程序更快的那一个。此外，还要考虑其他可能提供更好性能或兼容性的MPI实现，例如MVAPICH（可以获得最佳的InfiniBand性能）或Intel MPI（受到广泛支持的ISV）。HP公司努力使其MPI符合许多ISV代码的资格，但在被出售给Platform后，我不确定它的表现如何...

- Funcan

2

根据我的经验，OpenMPI支持而MPICH不支持的一个好功能是进程亲和性。例如，在OpenMPI中，使用-npersocket可以设置在每个插座上启动的排名数量。此外，当您想要将排名定位到核心或超额订阅它们时，OpenMPI的rankfile非常方便。最后，如果您需要控制排名到核心的映射，我强烈建议使用OpenMPI编写和编译代码。

- hmofrad

2

MPICH支持亲和性。https://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager#Process-core_Binding - Jeff Hammond

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Jeff Hammond · Accepted Answer

目的

首先，重要的是要认识到MPICH和Open-MPI之间的区别，即它们旨在满足不同的需求。MPICH应该是最新MPI标准的高质量参考实现，并且是衍生实现以满足特殊目的需求的基础。Open-MPI针对常见情况进行优化，包括使用和网络通道。

网络技术支持

Open-MPI文档记录了他们的网络支持，这里。MPICH在每个版本分发的README中列出了这些信息（例如这里是3.2.1版）。请注意，由于Open-MPI和MPICH都支持OFI（又名libfabric）网络层，因此它们支持许多相同的网络。但是，libfabric是一个多方面的API，因此不是每个网络在两者中都得到相同的支持（例如，MPICH具有基于OFI的IBM Blue Gene / Q实现，但我不知道Open-MPI中是否有等效的支持）。但是，MPICH和Open-MPI的基于OFI的实现正在共享内存、以太网（通过TCP/IP）、Mellanox InfiniBand、Intel Omni Path和可能其他网络上运行。Open-MPI还原生地支持这两种网络和其他网络（即没有OFI在中间）。

过去，人们普遍抱怨MPICH不支持InfiniBand，而Open-MPI支持。然而，MVAPICH和Intel MPI（等等） - 都是MPICH的派生物 - 支持InfiniBand，因此如果愿意将MPICH定义为“MPICH及其派生物”，那么MPICH具有极其广泛的网络支持，包括InfiniBand和专有互连，如Cray Seastar、Gemini和Aries以及IBM Blue Gene (/L、/P和/Q)。Open-MPI也支持Cray Gemini互连，但Cray不支持其使用。最近，MPICH通过一个现已弃用的netmod支持InfiniBand，但MVAPICH2具有广泛的优化，几乎在所有情况下都是首选实现。

最新MPI标准的功能支持

硬件/平台支持的正交轴是MPI标准的覆盖范围。在这方面，MPICH通常是远远优于其他实现的。从MPI-1到MPI-3，MPICH一直是每个版本MPI标准的第一个实现。Open-MPI只最近支持了MPI-3，我发现一些MPI-3特性在某些平台上存在缺陷（当然，MPICH并非没有漏洞，但MPI-3特性的漏洞要少得多）。

历史上，Open-MPI没有对于MPI_THREAD_MULTIPLE提供全面的支持，这对于某些应用程序至关重要。它可能在某些平台上得到支持，但不能普遍地假设它可以工作。另一方面，MPICH多年来一直对MPI_THREAD_MULTIPLE提供全面的支持，尽管实现并不总是高性能的（参见"Locking Aspects in Multithreaded MPI Implementations"以获取一种分析）。

在Open-MPI 1.x中破坏的另一个功能是单边通信，也称为RMA。最近已经修复了这个问题，作为这些功能的非常重度用户，我发现它们在Open-MPI 3.x中通常运行良好（请参见ARMCI-MPI test matrix in Travis CI，其中显示了RMA与两种实现的结果，至少在共享内存中。我在Intel Omni Path上看到了类似的积极结果，但尚未测试Mellanox InfiniBand。

进程管理

Open-MPI曾经在进程管理方面明显优于MPICH。旧版的MPICH启动程序（MPD）容易出现故障且难以使用。幸运的是，它已经被弃用多年（详见MPICH FAQ entry）。因此，因为MPD而批评MPICH是无稽之谈。

Hydra进程管理器非常好，具有与ORTE（在Open-MPI中）相似的可用性和功能集，例如，两者都支持HWLOC以控制进程拓扑。有报道称，在处理更大的作业（1000个或以上的进程）时，Open-MPI的进程启动速度比MPICH衍生产品快，但由于我在这方面没有第一手经验，因此不确定该得出什么结论。这种性能问题通常是特定于网络甚至特定于机器的。

使用MacOS和VPN时，我发现Open-MPI更加稳健，即MPICH可能会因主机名解析问题而挂起启动。由于这是一个错误，此问题可能会在未来消失。

二进制可移植性

尽管MPICH和Open-MPI都是开源软件，可以在各种平台上进行编译，但MPI库以二进制形式或与之链接的程序的可移植性通常很重要。

MPICH及其许多衍生产品支持ABI兼容性(website)，这意味着库的二进制接口是恒定的，因此可以使用来自一个实现的mpi.h进行编译，然后在另一个实现中运行。即使在库的多个版本之间也是如此。例如，我经常编译Intel MPI，但在运行时使用MPICH的开发版本的LD_PRELOAD。ABI兼容性的一个巨大优势是独立软件供应商(ISV)可以发布针对MPICH系列的一个成员编译的二进制文件。

ABI并不是唯一的二进制兼容性类型。上述场景假定用户在所有地方使用相同版本的MPI启动器(通常是mpirun或mpiexec，以及其计算节点守护程序)和MPI库。但这在容器中并不一定成立。

虽然 Open-MPI 没有承诺 ABI 兼容性，但他们在支持容器方面投入了大量精力（docs，slides）。这需要非常小心地维护 MPI 启动器、启动器守护程序和 MPI 库在不同版本之间的兼容性，因为用户可能使用比容器支持的启动器守护程序更新的 MPI 启动器版本启动作业。如果不仔细注意启动器接口稳定性，则容器作业将无法启动，除非每个启动器组件的版本都兼容。这不是一个难以克服的问题：

例如，Docker 世界使用的解决方法是将基础架构与应用程序一起放入容器中。换句话说，您将 MPI 守护程序与应用程序一起放入容器中，然后要求所有容器（包括 mpiexec）具有相同的版本。这样就避免了跨版本基础架构操作的问题。

我感谢 Open-MPI 团队的 Ralph Castain 向我解释了容器问题。上述引用是他的话。

平台特定比较

以下是我对各个平台的评估：

苹果电脑上：Open-MPI和MPICH都可以正常工作。如果想要使用MPI-3标准的最新功能，则需要使用来自Homebrew的最新版本的Open-MPI。如果您在Mac笔记本电脑上运行，就没有理由考虑MPI性能。
共享内存的Linux系统上：Open-MPI和MPICH都可以正常工作。如果您想要一个支持MPI-3或MPI_THREAD_MULTIPLE的发行版本，除非您自己构建Open-MPI，否则可能需要使用MPICH，因为例如Ubuntu 16.04仅通过APT提供古老版本1.10。我不知道这两个实现之间是否有任何显着的性能差异。如果操作系统允许，两者都支持单拷贝优化。
搭载Mellanox InfiniBand的Linux系统上：请使用Open-MPI或MVAPICH2。如果您想要一个支持MPI-3或MPI_THREAD_MULTIPLE的发行版本，您可能需要使用MVAPICH2。我发现MVAPICH2表现非常好，但尚未直接与InfiniBand上的OpenMPI进行比较，其中对我来说性能最重要的特性（RMA aka one-sided）过去曾在Open-MPI中出现问题。
搭载Intel Omni Path（或其前身True Scale）的Linux系统：我在这些系统上使用了MVAPICH2、Intel MPI、MPICH和Open-MPI，并且它们都可以正常工作。因为Open-MPI具有经过优化的基于PSM2的后端，所以在开源实现中提供了最佳性能，而Intel MPI则倾向于最优化。我在GitHub上有一些关于如何构建不同开源实现的注释，但是这样的信息很快就会过时。
Cray或IBM超级计算机：MPI会自动安装在这些计算机上，并且在两种情况下都基于MPICH。已经演示了MPICH在Cray XC40上（here）使用OFI，Intel MPI在Cray XC40上（here）使用OFI，MPICH在Blue Gene/Q上使用OFI（here），以及Open-MPI在Cray XC40上同时使用OFI和uGNI（here），但这些都不得到供应商支持。
Windows：我认为在Windows上运行MPI没有意义，除非通过Linux VM进行，但是Microsoft MPI和Intel MPI都支持Windows并基于MPICH。我听说成功构建了MPICH或Open-MPI使用Windows Subsystem for Linux，但我没有个人经验。

笔记

完全透明地说，我目前在英特尔担任研究/探索职务（即我不从事任何英特尔软件产品的工作），曾在阿贡国家实验室工作了五年，在那里我与MPICH团队进行了广泛的合作。