2

単一のサーバーがあり、2 つのプロセス タイプ A (多数のプロセスが多数のスレッドを処理する) と B (1 つのプロセスが n-cpu の n スレッド) を持っていて、大量の一方向メッセージを A から B に送信したいとします。 . MPI は、以下を使用するカスタム実装よりも優れた実装ですか?

  1. Unix ドメインソケット
  2. Windows 名前付きパイプ
  3. 共有メモリ

1 と 2 に基づいて独自のライブラリを作成することを考えていましたが、共有メモリにはロックが必要になるため、3 の方が優れているかどうかも疑問に思っています。

プロセス A は外部サービスを提供するため、B のリソースの使用と一般的なメッセージ パッシングはできるだけ少ないリソースを消費する必要があり、A はメッセージを送信するときにブロッキングまたは非ブロッキングの両方で実装できます。B のリソース使用量とメッセージ パッシングは、A の使用量に比例してスケーリングする必要があります。

最終的には、マシン間のブロードキャスト機能も必要になります。おそらくプロセスBです。

私の別れの質問は、MPI (特に openMPI) はこれに適したライブラリであり、さまざまなオペレーティング システムで最適なカーネル プリミティブを使用するかどうかです。

4

2 に答える 2

3

MPI は、メッセージ パッシング インフラストラクチャに適合するようにアーキテクチャを再構築する意思がある場合、これに適している可能性が高くなります。

理論的には、少なくとも単一のサーバーでホストされている場合、独自のライブラリをラップすると、MPI メッセージ構造に出入りする必要がないという理由だけで、何かをより速く実行できる可能性があります。そうは言っても、MPI は非常に効率的で (特にOpen MPIがサポートする MPI-2)、非常に堅牢です。自分のライブラリから同じ柔軟性、構成可能性、および堅牢性を得るのは難しいでしょう。

複数のマシン間でブロードキャストする場合は、独自の方法を試すよりも MPI の方がおそらく優れたアプローチです。

また、MPI は多数の通信モードをサポートしています。非常に高速な単一マシン通信用の共有メモリと、マシン間通信用の TCP (およびいくつかの商用の高速オプション) をサポートしています。

于 2009-12-09T18:38:20.997 に答える
2

MPI は非常に効率的で、高性能アプリケーション向けに構築されています。
同じ mboard 上の CPU 間の通信にも使用できます。

ブロードキャストについてはわかりません。私が何年も前に使用していたシステムではそうではありませんでしたが、それが相互接続の制限だったのか、MPICH の制限だったのか思い出せません。

ps。MPICH を使用したのは、当時 Windows で最適に機能し、その柔軟性が必要だったからです。私は MPICH2 や OpenMPI を使用したことがありません。

于 2009-12-09T18:27:54.450 に答える