目的
まず、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はInfiniBandをnetmod（現在は非推奨）でサポートしていますが、MVAPICH2には広範な最適化が施されており、ほとんどすべての場合に推奨される実装となっています。
最新のMPI標準からの機能サポート
ハードウェア/プラットフォームサポートに対する直交軸は、MPI標準の範囲です。ここでMPICHは通常、はるかに優れています。MPICHは、MPI-1からMPI-3まで、MPI標準のすべてのリリースの最初の実装でした。Open-MPIは最近サポートされたMPI-3であり、一部のMPI-3機能には一部のプラットフォームでバグがあることがわかりました（もちろん、MPICHにはバグがないわけではありませんが、MPI-3機能のバグはそれほど一般的ではありません）。
歴史的に、Open-MPIはを全面的にサポートしていないためMPI_THREAD_MULTIPLE、一部のアプリケーションにとって重要です。一部のプラットフォームではサポートされている可能性がありますが、通常は動作するとは想定できません。一方、MPICHはMPI_THREAD_MULTIPLE長年にわたって包括的なサポートを提供してきましたが、実装は必ずしも高性能ではありません（1つの分析については、「マルチスレッドMPI実装でのアスペクトのロック」を参照してください）。
Open-MPI 1.xで壊れたもう1つの機能は、RMAとも呼ばれる片側通信です。これはより最近修正され、これらの機能の非常にヘビーユーザーとして、Open-MPI 3.xで一般にうまく機能していることがわかりました（たとえば、RMAの動作を示す結果については、Travis CIのARMCI-MPIテストマトリックスを参照してください）少なくとも共有メモリでの両方の実装インテルOmniパスで同様の肯定的な結果が見られましたが、Mellanox InfiniBandはテストしていません。
プロセス管理
Open-MPIが非常に優れていた領域の1つは、プロセスマネージャーでした。古いMPICH起動（MPD）は壊れやすく、使用するのが困難でした。幸いなことに、長年にわたって非推奨になっています（詳細については、MPICH FAQエントリを参照してください）。したがって、MPDによるMPICHへの批判は偽りです。
Hydraプロセスマネージャーは非常に優れており、ORTE（Open-MPI）と同様の使いやすさと機能セットを備えています。たとえば、どちらもプロセストポロジーを制御するHWLOCをサポートしています。Open-MPIプロセスの起動は、大規模なジョブ（1000以上のプロセス）のMPICH派生物よりも高速であるという報告がありますが、私はここでの直接の経験がないため、結論を述べるのは不安です。このようなパフォーマンスの問題は、通常、ネットワーク固有であり、場合によってはマシン固有でもあります。
VPNでMacOSを使用する場合、Open-MPIの方が堅牢であることがわかりました。つまり、ホスト名解決の問題が原因で、MPICHが起動時にハングする可能性があります。これはバグなので、この問題は将来なくなる可能性があります。
バイナリ移植性
MPICHとOpen-MPIはどちらも、幅広いプラットフォームでコンパイルできるオープンソースソフトウェアですが、バイナリ形式のMPIライブラリ、またはそれらにリンクされたプログラムの移植性がしばしば重要になります。
MPICHとその派生物の多くはABI互換性（Webサイト）をサポートしています。これは、ライブラリへのバイナリインターフェイスが一定であるため、1 mpi.hつの実装からコンパイルして別の実装で実行できることを意味します。これは、ライブラリの複数のバージョン間でも当てはまります。たとえば、インテルMPIを頻繁にコンパイルしますがLD_PRELOAD、実行時に開発バージョンのMPICHをコンパイルします。ABI互換性の大きな利点の1つは、ISV（独立系ソフトウェアベンダー）がMPICHファミリの1つのメンバーに対してのみコンパイルされたバイナリをリリースできることです。
ABIだけがバイナリ互換性のタイプではありません。シナリオは、ユーザが同じMPIランチャーのバージョン（通常使用することを前提と上記mpirunまたは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をすべてサポートするリリースバージョンが必要な場合は、Open-MPIを自分でビルドしない限り、おそらくMPICHが必要になります。たとえば、Ubuntu 16.04はAPTを介して古いバージョン1.10しか提供しないためです。2つの実装のパフォーマンスに大きな違いはありません。OSで許可されている場合、どちらも単一コピーの最適化をサポートします。
Mellanox InfiniBandを使用するLinux：Open-MPIまたはMVAPICH2を使用します。MPI-3またはのすべてをサポートするリリースバージョンMPI_THREAD_MULTIPLEが必要な場合は、MVAPICH2が必要になる可能性があります。MVAPICH2は非常にうまく機能しますが、パフォーマンスが最も重要である機能（RMA、片側）が過去にOpen-MPIで機能しなくなったため、InfiniBandでOpenMPIと直接比較していません。
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のIntel MPI（ここ）、OFIを使用したBlue Gene / QのMPICH（ここ）、およびOFIとuGNIの両方を使用したCray XC40のOpen-MPIのデモがあります。 （こちら）、ただしこれらはベンダーでサポートされていません。
Windows：Linux VM以外でWindowsでMPIを実行しても意味がありませんが、Microsoft MPIとIntel MPIはどちらもWindowsをサポートしており、MPICHベースです。Linux用のWindowsサブシステムを使用したMPICHまたはOpen-MPIのビルドが成功したという報告を聞いたことがありますが、個人的な経験はありません。
ノート
完全な開示として、私は現在、リサーチ/パスファインディングの能力でIntelに勤務しており（つまり、Intelソフトウェア製品には従事していません）、以前はアルゴンヌ国立研究所に5年間勤務し、MPICHチームと広範囲に協力しました。