mpi - MPICH と OpenMPI

Question

MPI の OpenMPI 実装と MPICH 実装の違いを誰か詳しく説明できますか? どちらがより良い実装ですか?

Answer 1

目的

まず、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 に関する一般的な不満は、Open-MPI がサポートしているのに対し、MPICH は InfiniBand をサポートしていないというものでした。ただし、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 がはるかに優れています。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 テスト マトリックスを参照してください)。 Intel Omni Path でも同様の肯定的な結果が得られましたが、Mellanox InfiniBand はテストしていません。

プロセス管理

Open-MPI が非常に優れていた領域の 1 つは、プロセス マネージャーでした。古い MPICH 起動 (MPD) は脆弱で使いにくかったです。幸いなことに、これは何年も前から廃止されています (詳細については、MPICH FAQ エントリを参照してください)。したがって、MPD による MPICH の批判は偽りです。

Hydra プロセス マネージャーは非常に優れており、ORTE (Open-MPI の場合) と同様の使いやすさと機能セットを備えています。たとえば、どちらもプロセス トポロジを制御するために HWLOC をサポートしています。大規模なジョブ (1000 以上のプロセス) では、Open-MPI プロセスの起動が MPICH 派生よりも高速であるという報告がありますが、私はここで直接の経験がないため、結論を述べることに抵抗があります。このようなパフォーマンスの問題は通常、ネットワーク固有であり、場合によってはマシン固有です。

VPN で MacOS を使用する場合、Open-MPI の方が堅牢であることがわかりました。つまり、MPICH は、ホスト名の解決の問題により起動時にハングする場合があります。これはバグであるため、この問題は今後解消される可能性があります。

バイナリの移植性

MPICH と Open-MPI はどちらも、幅広いプラットフォームでコンパイルできるオープンソース ソフトウェアですが、バイナリ形式の MPI ライブラリ、またはそれらにリンクされたプログラムの移植性は、多くの場合重要です。

MPICH とその派生物の多くは ABI 互換性をサポートしています ( Web サイト)。これは、ライブラリへのバイナリ インターフェイスが一定であるため、mpi.hある実装からコンパイルして、別の実装で実行できることを意味します。これは、複数のバージョンのライブラリにまたがっても当てはまります。たとえば、私は頻繁に Intel 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 が必要です。2 つの実装の間でパフォーマンスに大きな違いがあることは認識していません。OS で許可されている場合、どちらもシングル コピーの最適化をサポートします。

• Mellanox InfiniBand を使用する Linux: Open-MPI または MVAPICH2 を使用します。MPI-3 または のすべてをサポートするリリース バージョンMPI_THREAD_MULTIPLEが必要な場合は、MVAPICH2 が必要になる可能性があります。MVAPICH2 のパフォーマンスは非常に優れていることがわかりましたが、InfiniBand で OpenMPI と直接比較したことはありません。その理由の 1 つは、私にとってパフォーマンスが最も重要な機能 (RMA 別名片側) が過去に Open-MPI で壊れていたためです。

• Intel Omni Path (またはその前身である True Scale) を搭載した Linux: そのようなシステムで MVAPICH2、Intel MPI、MPICH、および Open-MPI を使用しましたが、すべて動作しています。Intel 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 ベースです。Windows Subsystem for Linuxを使用して MPICH または Open-MPI のビルドが成功したという報告を聞いたことがありますが、個人的な経験はありません。

ノート

完全な開示では、私は現在、研究/経路探索の能力でインテルに勤務しており (つまり、インテルのソフトウェア製品には携わっていません)、以前はアルゴンヌ国立研究所に 5 年間勤務し、そこで MPICH チームと広範囲に協力しました。

Answer 2

本番システムではなく開発を行う場合は、MPICH を使用してください。MPICH にはデバッガーが組み込まれていますが、Open-MPI は確認したときに持続しませんでした。

本番環境では、Open-MPI の方が高速になる可能性が高くなります。ただし、Intel MPI などの他の代替手段を調査することもできます。

Answer 3

前のポスターに同意します。両方を試して、どちらの方がアプリケーションの実行速度が速いかを確認してから、本番環境で使用してください。どちらも規格に準拠しています。デスクトップであればどちらでも構いません。OpenMPI は Macbook でそのまま使用でき、MPICH はより Linux/Valgrind に適しているようです。それはあなたとあなたのツールチェーンの間にあります。

実稼働クラスターの場合は、より広範なベンチマークを実行して、ネットワーク トポロジーに最適化されていることを確認する必要があります。本番クラスターでの構成は、RTFM を行う必要があるため、時間の点で主な違いになります。

Answer 4

どちらも標準に準拠しているため、正当性の観点からどちらを使用してもかまいません。特定のデバッグ拡張機能など、必要な機能がない限り、両方のベンチマークを実行し、ハードウェア上のアプリでどちらか速い方を選択します。また、MVAPICH（最高のInfiniBandパフォーマンスを実現できる）やIntel MPI（広くサポートされているISV）など、パフォーマンスや互換性を向上させる可能性のある他のMPI実装があることも考慮してください。HPは、MPIを多くのISVコードで認定するために一生懸命努力しましたが、プラットフォームに販売された後、それがどのように進んでいるかはわかりません...