目的
首先，重要的是要认识到MPICH和Open-MPI有何不同，即它们旨在满足不同的需求。MPICH被认为是最新MPI标准的高质量参考实现，并且是满足特殊目的的派生实现的基础。开放式MPI既针对使用情况，又针对网络管道。
支持网络技术
Open-MPI 在此处记录了其网络支持。MPICH在随每个版本一起分发的自述文件中列出了此信息（例如，这适用于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，这对于某些应用程序至关重要。在某些平台上可能会支持它，但通常不能认为它可以工作。另一方面，MPI_THREAD_MULTIPLE尽管MPICH 的实现并不总是高性能的，但它已经获得了多年的全面支持（有关分析，请参阅“多线程MPI实现中的锁定方面”）。
Open-MPI 1.x的另一个功能是单面通信，也称为RMA。最近，此问题已得到解决，并且我发现，作为这些功能的重度用户，它们通常在Open-MPI 3.x中运行良好（请参阅例如Travis CI中的ARMCI-MPI测试矩阵以了解显示RMA与这两种实现方式，至少是在共享内存中，我已经在Intel Omni Path上看到了类似的积极结果，但是还没有测试Mellanox InfiniBand。
流程管理
流程管理器是Open-MPI过去曾经非常出色的一个领域。旧的MPICH发射（MPD）较脆且难以使用。幸运的是，它已被弃用很多年（有关详细信息，请参阅MPICH FAQ条目）。因此，由于MPD而对MPICH的批评是虚假的。
Hydra流程管理器非常出色，并且具有与ORTE（在Open-MPI中）相似的可用性和功能集，例如都支持HWLOC来控制流程拓扑。有报告称，Open-MPI流程的启动速度比MPICH衍生产品更快（适用于1000多个流程），但是由于我在这里没有第一手经验，因此我不愿意陈述任何结论。此类性能问题通常是特定于网络的，有时甚至是特定于计算机的。
我发现将MacOS与VPN一起使用时，Open-MPI更加健壮，即由于主机名解析问题，MPICH可能会在启动时挂起。由于这是一个错误，此问题将来可能会消失。
二进制可移植性
尽管MPICH和Open-MPI都是可以在多种平台上编译的开源软件，但是MPI库（以二进制形式）或与之链接的程序的可移植性通常很重要。
MPICH及其许多派生工具都支持ABI兼容性（网站），这意味着库的二进制接口是恒定的，因此可以mpi.h从一种实现中进行编译，然后再与另一种实现一起运行。即使在多个版本的库中也是如此。例如，我经常LD_PRELOAD在运行时编译Intel MPI但编译为MPICH。ABI兼容性的一大优势是ISV（独立软件供应商）可以仅针对MPICH系列的一个成员发布编译的二进制文件。
ABI不是唯一的二进制兼容性类型。上述方案假定用户在所有地方都使用相同版本的MPI启动器（通常为mpirunor mpiexec，以及其计算节点守护程序）和MPI库。容器不一定是这种情况。
尽管Open-MPI不能保证与ABI兼容，但他们在支持容器（docs，slides）上进行了大量投资。这需要在维护MPI启动器，启动器守护程序和MPI库的不同版本之间的兼容性时格外小心，因为与容器支持中的启动器守护程序相比，用户可以使用较新版本的MPI启动器来启动作业。如果不特别注意启动器界面的稳定性，除非启动器每个组件的版本兼容，否则容器作业将无法启动。这不是一个无法解决的问题：
例如，Docker世界使用的解决方法是将基础架构与应用程序一起容器化。换句话说，您将MPI守护程序包含在应用程序本身的容器中，然后要求所有容器（包括mpiexec）具有相同的版本。由于您不再具有跨版本的基础架构操作，因此可以避免该问题。
我感谢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的优化后端。我在GitHub上有一些有关如何构建不同的开源实现的说明，但是这些信息很快就过时了。
Cray或IBM超级计算机：MPI会自动安装在这些计算机上，并且在两种情况下均基于MPICH。已经演示了使用OFI的 Cray XC40上的MPICH（此处），使用OFI的 Cray XC40上的英特尔MPI（此处），使用OFI的Blue Gene / Q上的MPICH（此处）以及使用OFI和uGNI的Cray XC40上的Open-MPI。 （此处），但是这些都不是供应商支持的。
Windows：除通过Linux VM之外，在Windows上运行MPI毫无意义，但Microsoft MPI和Intel MPI均支持Windows，并且基于MPICH。我听说过使用Windows子系统（用于Linux）成功构建MPICH或Open-MPI的报告，但没有任何个人经验。
笔记
经过全面披露，我目前以研究/开拓能力为英特尔工作（即，我不从事任何英特尔软件产品的工作），并曾在Argonne国家实验室工作了五年，在那里我与MPICH团队进行了广泛的合作。