mpi - MPICH与OpenMPI

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

最佳答案

目的

首先，重要的是要认识到MPICH和Open-MPI有何不同，即它们旨在满足不同的需求。 MPICH被认为是最新MPI标准的高质量引用实现，并且是满足特殊目的的派生实现的基础。开放式MPI既针对使用情况，又针对网络管道。

支持网络技术

Open-MPI记录了其网络支持here。 MPICH在随每个版本一起分发的自述文件中列出了此信息(例如this用于3.2.1)。请注意，由于Open-MPI和MPICH均支持OFI(aka libfabric)网络层，因此它们支持许多相同的网络。但是，libfabric是一个多方面的API，因此并非每个网络都可以同时受支持(例如，MPICH具有基于OFI的IBM Blue Gene / Q实现，但是我不知道Open-MPI中的等效支持) 。但是，基于OFI的MPICH和Open-MPI的实现都在共享内存，以太网(通过TCP / IP)，Mellanox InfiniBand，英特尔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与这两种实现一起使用的结果，至少是在共享时使用) -memory。我在Intel Omni Path上看到了类似的积极结果，但是还没有测试Mellanox InfiniBand。

流程管理

流程管理器是Open-MPI过去曾经非常出色的一个 Realm 。旧的MPICH发射(MPD)较脆且难以使用。幸运的是，它已被弃用多年(有关详细信息，请参见MPICH FAQ entry)。因此，由于MPD而对MPICH的批评是虚假的。

Hydra流程管理器非常出色，并且具有与ORTE(在Open-MPI中)类似的可用性和功能集，例如两者都支持HWLOC来控制过程拓 flutter 。有报告称，Open-MPI程序的启动速度比MPICH派生程序更快(适用​​于1000多个程序)，但是由于我在这里没有第一手经验，因此我不愿意陈述任何结论。此类性能问题通常是特定于网络的，有时甚至是特定于机器的。

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

二进制可移植性

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

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

ABI不是唯一的二进制兼容性类型。上面描述的方案假定用户到处都使用相同版本的MPI启动器(通常是mpirun或mpiexec以及其计算节点守护程序)和MPI库。容器不一定是这种情况。

尽管Open-MPI不能保证与ABI兼容，但他们在支持容器(docs，slides)上投入了大量资金。这需要在维护MPI启动器，启动器守护程序和MPI库的不同版本之间的兼容性时格外小心，因为与容器支持中的启动器守护程序相比，用户可以使用较新版本的MPI启动器来启 Action 业。如果不特别注意启动器界面的稳定性，除非启动器每个组件的版本兼容，否则容器作业将无法启动。这不是一个无法解决的问题:



我感谢Open-MPI团队的Ralph Castain向我解释了容器问题。前面的报价是他的。

特定于平台的比较

这是我对各个平台的评估:

Mac OS:Open-MPI和MPICH都应该可以正常工作。要获得MPI-3标准的最新功能，您需要使用Homebrew提供的最新版本的Open-MPI。如果您在Mac笔记本电脑上运行，则没有理由考虑MPI性能。

具有共享内存的Linux:Open-MPI和MPICH应该都可以正常工作。如果您想要一个支持所有MPI-3或MPI_THREAD_MULTIPLE的发行版，则可能需要MPICH，除非您自己构建Open-MPI，因为例如Ubuntu 16.04仅通过APT提供旧版本1.10。我不知道这两种实现之间的任何显着性能差异。如果操作系统允许，两者都支持单副本优化。

带有Mellanox InfiniBand的

Linux:使用Open-MPI或MVAPICH2。如果要支持所有MPI-3或MPI_THREAD_MULTIPLE的发行版，则可能需要MVAPICH2。我发现MVAPICH2的性能非常好，但没有与InfiniBand上的OpenMPI进行直接比较，部分原因是性能对我而言最重要的功能(RMA，又称单面)在过去的Open-MPI中已被破坏。

带有Intel Omni Path(或其前身，True Scale)的

Linux:我在此类系统上使用了MVAPICH2，Intel MPI，MPICH和Open-MPI，并且都在工作。英特尔MPI倾向于最优化，而Open-MPI则提供了开源实现的最佳性能，因为它们具有经过优化的基于PSM2的后端。关于如何构建不同的开源实现，我有一些notes on GitHub，但是这种信息很快就过时了。

Cray或IBM super 计算机:MPI会自动安装在这些计算机上，并且在两种情况下均基于MPICH。在Cray XC40(here)上使用OFI进行了MPICH演示，在Cray XC40(here)上使用OFI的英特尔MPI，在Blue Gene / Q上使用OFI(here)的MPICH以及在Cray XC40上同时使用OFI和uGNI的Open-MPI进行了演示(here)，但都不支持任何供应商。

Windows:我认为除了通过Linux VM之外，在Windows上运行MPI毫无意义，但是Microsoft MPI和Intel MPI均支持Windows，并且基于MPICH。我听说过使用Windows Subsystem for Linux成功构建MPICH或Open-MPI的报告，但没有任何个人经验。

笔记

在全面披露的情况下，我目前以研究/探索能力为英特尔工作(即我不从事任何英特尔软件产品的工作)，并且曾在Argonne国家实验室工作了五年，在那里我与MPICH团队进行了广泛的合作。