一部のデータ処理のために疎結合クラスターに取り組んでいます。ネットワーク コードと処理コードは用意されていますが、私たちのアプローチではさまざまな方法論を評価しています。現在、当然のことながら、パフォーマンスの問題で I/O バウンドになっており、そのボトルネックを減らそうとしています。明らかに、Infiniband のようなより高速なスイッチはすばらしいものですが、持っているものを捨てて新しい機器を手に入れるという贅沢はできません。
私の質問はこれです。クラスタ上で実行されるすべての従来型および本格的な HPC アプリケーションは、通常、ソケットを介して直接送信するのではなく、メッセージ パッシングを使用して実装されます。これによるパフォーマンス上の利点は何ですか? ソケットから切り替えた場合、スピードアップが見られるでしょうか?
MPI はソケットを使用する可能性があります。しかし、直接分散共有メモリを使用する SAN (システム エリア ネットワーク) で使用される MPI 実装もあります。もちろん、そのためのハードウェアがあれば。そのため、MPI を使用すると、将来そのようなリソースを使用できます。その場合、大幅なパフォーマンスの向上を得ることができます (大学時代にクラスターを使用した私の経験では、数桁の向上に達する可能性があります)。そのため、ハイエンド クラスターに移植できるコードを作成している場合は、MPI を使用することをお勧めします。
パフォーマンスの問題を無視しても、MPI を使用すると多くの時間を節約でき、システムの他の部分のパフォーマンスを改善したり、単に正気を保ったりするために使用できます。
そのようなことが得意でない限り、自分で作成するのではなく、MPI を使用することをお勧めします。私自身のプロトコルを使用していくつかの分散コンピューティング風のアプリケーションを作成したことがありますが、MPI 内にある機能を再現している (そして再現性が低い) ことにいつも気付きます。
パフォーマンスに関しては、MPI が目に見えるネットワークの高速化をもたらすとは思いません。MPI はあなたと同じようにソケットを使用します。ただし、MPI は、ノード間の同期など、多くのノードを管理するために必要な多くの機能を提供します。
この場合、高性能クラスターであっても、パフォーマンスだけが考慮事項ではありません。MPIは標準APIを提供し、「ポータブル」です。異なるバージョンのMPI間でアプリケーションを切り替えるのは比較的簡単です。
ほとんどのMPI実装は、TCPベースの通信にソケットを使用します。ソケットを直接使用する自家製のアプリケーションよりも、特定のMPI実装が最適化され、メッセージパッシングが高速になる可能性があります。
さらに、InfiniBandを備えたクラスターでコードを実行する機会があった場合、MPIレイヤーはそれらのコード変更を抽象化します。これは些細な利点ではありません。OFED（または別のIB動詞）の実装を直接使用するようにアプリケーションをコーディングすることは非常に困難です。
ほとんどのMPIアプリケーションには、アプリケーションとは関係なくネットワーク設定の正確さを検証するために使用できる小さなテストアプリが含まれています。これは、アプリケーションをデバッグするときに大きな利点になります。MPI標準には、MPI呼び出しをプロファイリングするための「pMPI」インターフェイスが含まれています。このインターフェイスを使用すると、すべてのメッセージパッシングルーチンにチェックサムやその他のデータ検証を簡単に追加することもできます。
メッセージ パッシングは技術ではなくパラダイムです。最も一般的なインストールでは、MPI はソケットを使用して通信します。MPI に切り替えることで速度が向上する可能性がありますが、ソケット通信を最適化していない場合に限られます。
アプリケーションの I/O バウンドはどのようになっていますか? データブロックを作業ノードに転送する際にバインドされますか、それとも計算中の通信のためにバインドされますか?
答えが「通信のため」である場合、密結合のアプリケーションを作成し、それを疎結合タスク用に設計されたクラスターで実行しようとしていることが問題です。パフォーマンスを向上させる唯一の方法は、より優れたハードウェア (より高速なスイッチ、インフィニバンドなど) を入手することです。他の誰かの HPC で時間を借りることはできますか?
答えが「データ ブロック」転送である場合は、ワーカーに複数のデータ ブロックを割り当てることを検討し (ワーカーがより長くビジー状態になるようにする)、転送前にデータ ブロックを圧縮します。これは、疎結合のアプリケーションで役立つ戦略です。
OldMan と freespace に同意する必要があります。MPI に対する特定の有用な指標 (パフォーマンス、保守性など) の改善を知らない限り、車輪を再発明する必要はありません。MPI は、解決しようとしている問題に関する大量の共有知識を表します。
データを送信するだけでなく、対処しなければならない問題が数多くあります。接続のセットアップとメンテナンスはすべてあなたの責任になります。MPI がまさに必要な抽象化である場合 (そのように聞こえます)、それを使用してください。
少なくとも、MPI を使用し、後で独自のシステムでリファクタリングすることは、MPI のインストールと依存関係を犠牲にする良いアプローチです。
私は、MPI が単純なソケット通信をはるかに超えたものを提供するという OldMan の指摘を特に気に入っています。透過的な抽象化を使用して、多数の並列および分散コンピューティングの実装を取得できます。
私は MPI を使用したことはありませんが、ソケットはかなり使用しました。高性能ソケットについて考慮すべき点がいくつかあります。多くの小さなパケットを処理していますか、それとも大きなパケットを処理していますか? 多くの小さなパケットを処理している場合は、応答を高速化するために Nagle アルゴリズムをオフにすることを検討してください。
setsockopt(m_socket, IPPROTO_TCP, TCP_NODELAY, ...);
また、信号を使用すると、大量のデータを取得しようとすると、実際にははるかに遅くなる可能性があります。ずっと前に、リーダーが信号を待ってパケットを読み取るテストプログラムを作成しました-それは約100パケット/秒を取得します。次に、ブロック読み取りを行ったところ、1 秒あたり 10000 回の読み取りが行われました。
ポイントは、これらすべてのオプションを見て、実際にテストすることです。条件が異なれば、さまざまなテクニックが速く/遅くなります。意見を聞くだけでなく、それを試してみることが重要です。これについては、Steve Maguire が "Writing Solid Code" で説明しています。彼は直観に反する多くの例を使用し、それらをテストして、コードをより良く/より速くするものを見つけます.
MPI は下でソケットを使用するため、実際の唯一の違いは、コードがインターフェースする API だけです。ソケットを直接使用している場合は、プロトコルを微調整できますが、それだけです。データで正確に何をしているのですか？
MPI はソケットを使用します。自分が何をしているのかを知っていれば、多くのメタ データを送信する必要がないため、おそらくソケットからより多くの帯域幅を取得できます。
しかし、自分が何をしているのかを知る必要があり、エラーが発生しやすくなる可能性があります。基本的に、mpi を独自のメッセージング プロトコルに置き換えます。