有人可以详细说明MPI的OpenMPI和MPICH实现之间的差异吗？哪两个是更好的实现？
首先,重要的是要认识到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中的等效支持) .然而,基于OFI的MPICH和Open-MPI实现正在共享存储器,以太网(通过TCP/IP),Mellanox InfiniBand,Intel Omni Path以及其他可能的网络.Open-MPI也支持这些网络和其他网络(即中间没有OFI).
过去,关于MPICH的一个常见抱怨是它不支持InfiniBand,而Open-MPI则支持.然而,MVAPICH和英特尔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通常远远优越.MPICH是MPI标准的每一个版本的第一个实现,从MPI-1到MPI-3.Open-MPI最近才支持MPI-3,我发现一些MPI-3功能在某些平台上存在问题(MPICH当然不是没有错误的,但MPI-3功能中的错误已经不常见了).
从历史上看,Open-MPI尚未得到全面支持MPI_THREAD_MULTIPLE,这对某些应用程序至关重要.它可能在某些平台上得到支持,但通常不能被认为是有效的.另一方面,MPICH多年来一直得到全面的支持MPI_THREAD_MULTIPLE,尽管实现并不总是高性能(参见"在多线程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多个流程),但由于我没有这方面的第一手经验,我不愿意提出任何结论.此类性能问题通常是特定于网络的,有时甚至是特定于机器的.
我发现当使用带有VPN的MacOS时,Open-MPI会更加强大,即MPICH可能因主机名解析问题而在启动时挂起.由于这是一个错误,这个问题将来可能会消失.
二进制便携性虽然MPICH和Open-MPI都是可以在各种平台上编译的开源软件,但是二进制形式的MPI库或与之相关的程序的可移植性通常很重要.
MPICH及其许多衍生产品支持ABI兼容性(网站),这意味着库的二进制接口是常量,因此可以mpi.h从一个实现编译,然后与另一个实现运行.即使在多个版本的库中也是如此.例如,我经常LD_PRELOAD在运行时编译Intel MPI但是MPICH的开发版本.ABI兼容性的一大优势是ISV(独立软件供应商)可以发布仅针对MPICH家族的一个成员编译的二进制文件.
ABI不是唯一的二进制兼容类型.上述场景假设用户使用相同版本的MPI启动程序(通常mpirun或mpiexec与其计算节点守护程序一起使用)和MPI库.容器的情况不一定如此.
虽然Open-MPI不承诺ABI兼容性,但他们在支持容器(文档,幻灯片)方面投入了大量资金.这需要非常谨慎地维护不同版本的MPI启动程序,启动程序守护程序和MPI库之间的兼容性,因为用户可以使用比容器支持中的启动程序守护程序更新版本的MPI启动程序启动作业.如果不仔细关注启动器界面稳定性,除非启动器的每个组件的版本兼容,否则容器作业将不会启动.这不是一个不可逾越的问题:
例如,Docker世界使用的解决方法是将基础架构与应用程序一起容纳.换句话说,您在容器中包含MPI守护程序与应用程序本身,然后要求所有容器(包括mpiexec)具有相同的版本.这可以避免此问题,因为您不再具有跨版本的基础结构操作.
我承认Open-MPI团队的Ralph Castain向我解释了容器问题.紧接在前的报价是他的.
特定于平台的比较以下是我在逐个平台上的评估:
Mac OS:Open-MPI和MPICH都应该可以正常工作.要获得MPI-3标准的最新功能,您需要使用最新版本的Open-MPI,可从Homebrew获得.如果你在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.已经在Cray XC40(此处)上使用OFI,英特尔MPI在Cray XC40(此处)使用OFI,使用OFI(此处)在Blue Gene/Q上使用MPICH ,以及使用OFI和uGNI在Cray XC40上使用Open-MPI进行MPICH演示(这里),但这些都不是供应商支持的.
Windows:除了Linux VM之外,我认为在Windows上运行MPI毫无意义,但Microsoft MPI和Intel MPI都支持Windows并且基于MPICH.我听说过使用适用于Linux的Windows子系统成功构建MPICH或Open-MPI的报告但没有个人经验.
笔记
在完全披露中,我目前在英特尔从事研究/寻路工作(即我不在任何英特尔软件产品上工作),并且曾在阿贡国家实验室工作了五年,在那里我与MPICH团队进行了广泛的合作.
如果您进行开发而不是生产系统,请使用MPICH.MPICH有内置的调试器,而Open-MPI不是我上次检查的.
在生产中,Open-MPI最有可能更快.但是,您可能希望研究其他替代方案,例如英特尔MPI.
我同意上一张海报.尝试两者查看您的应用程序运行速度更快,然后将其用于生产.它们都符合标准.如果它是你的桌面也没关系.OpenMPI在Macbook上开箱即用,MPICH似乎更适合Linux/Valgrind.它在你和你的工具链之间.
如果是生产群集,则需要进行更广泛的基准测试,以确保它针对您的网络拓扑进行了优化.在生产集群上配置它将是您在RTFM时间方面的主要区别.
两者都符合标准,因此从正确的角度来看,使用哪个都无关紧要.除非您需要某些功能(例如特定的调试扩展),然后对两者进行基准测试,并选择硬件上的应用程序更快的功能.还要考虑其他可能提供更好性能或兼容性的MPI实现,例如MVAPICH(可以具有最佳InfiniBand性能)或Intel MPI(广泛支持的ISV).惠普努力让他们的MPI获得了大量的ISV代码,但是我不确定它在被卖到平台之后是如何发展的......
京公网安备 11010802040832号 | 京ICP备19059560号-6 