5

先ほど完了した課題では、ランダムな Ubuntu マシンを MPI コンピューティング クラスター内のノードとして構成できる一連のスクリプトを作成する必要があります。これはすべて完了しており、ノードは互いに適切に通信できます。ただし、並列プログラムを実行して、MPI クラスターの効率を実証したいと思います。利用可能なプロセス (=ノード) の数の間で作業を分割できる単純な総当たり計算を探しているだけです: 1 つのノードがプログラムを実行するのに 10 秒かかる場合、4 つのノードは約 2.5 しかかからないはずです。

それを念頭に置いて、私は C で書かれた主要な計算プログラムを探しました。純粋主義者にとって、私が取っているコースは純粋にシステム管理であるため、プログラムは実際には私の課題の一部ではありません。クラスターが機能していることを示すものだけが必要です。プログラミングの経験はありますが、C の経験はほとんどなく、MPI の経験はありません。かなりの数のサンプル プログラムを見つけましたが、どれも実際に並列に実行されているようには見えません。それらはすべてのステップをノード間で分散するため、1 つのノードがより高速なプロセッサを備えている場合、全体の時間は短縮されますが、ノードを追加しても計算は高速化されません。

私は何か間違ったことをしていますか？私が見つけたプログラムは単純に並列ではありませんか? 独自のプログラムを作成するには、MPI の C プログラミングを学ぶ必要がありますか? クラスターが動作していることを示すために使用できる並列 MPI プログラムは他にありますか?

編集

以下の回答のおかげで、いくつかの MPI スクリプトを動作させることができました。その中で、最初の N 個の自然数の合計 (データ型の制限に達するため、あまり役に立ちません)、素数のカウントと生成、およびPi のモンテカルロ計算。興味深いことに、素数プログラムのみが、複数のノード/プロセスで (場合によっては劇的な) パフォーマンスの向上を実現します。

スクリプトを動作させる際の最初の問題のほとんどを引き起こした問題は、かなりわかりにくく、明らかにノード上のホスト ファイルの問題によるものでした。パラメーターを指定して mpiexec を実行すると、-disable-hostname-propagationこの問題が解決されました。MPI(R) バリア エラー、TCP 接続エラー、その他の一般的な接続エラーなど、さまざまな形で現れる可能性があります。クラスター内のすべてのノードがホスト名でお互いを認識している必要があると思いますが、これは、サーバー ノードで DHCP/DNS が実行されている従来の Beowulf クラスターでは実際には問題になりません。

4

2 に答える 2

4

並列プログラミングにおける通常の概念実証アプリケーションは、単純なレイトレーシングです。

そうは言っても、レイトレーシングは OpenMPI の能力を誇示するための良い例ではないと思います。MPI が真の力を発揮するのは、スキャッター/ギャザー、さらにはスキャッター/リデュースです:)

その最も基本的な例は、最初の N 個の整数の合計を計算することです。配列に合計する値の範囲に適合し、これらの範囲をワーカーの数に分散させるマスター スレッドが必要です。

次に、無料の検証テストを取得するために、還元を行い、明示的な式に対して結果を確認する必要があります。

MPI の弱点を探している場合は、IO がボトルネックである並列 grep が機能する可能性があります。

編集

MPI は、ノードがメッセージを使用して通信するシェアード ナッシング アーキテクチャに基づいており、ノードの数が固定されていることに留意する必要があります。これら 2 つの要因により、その上で実行されるプログラムのフレームが非常に狭くなります。簡単に言うと、この種の並列処理はデータ並列アプリケーションには最適ですが、タスク並列アプリケーションには適していません。ノードの数が変化した場合、通常はタスクよりもデータをうまく分散できるからです。

また、MPI には暗黙的なワークスティーリングの概念がありません。ノードが作業を終了すると、他のノードが終了するのを待つだけです。つまり、最も弱いリンクを自分で処理する必要があります。

MPI は、パフォーマンスの詳細に関して非常にカスタマイズ可能です。たとえば、MPI_SEND にはさまざまなバリエーションがあります。これは、MPI が設計されたハイ パフォーマンス コンピューティングにとって重要なパフォーマンス調整の余地を残しますが、ほとんどの場合、「普通の」プログラマーを混乱させ、並列実行するとプログラムが実際に遅くなります。多分あなたの例はただひどいです:)

そして、スケールアップ/スピードアップの問題については、まあ...

アムダールの法則を読むことをお勧めします。ノードを追加するだけでは線形の高速化は不可能であることがわかります:)

お役に立てば幸いです。まだ質問がある場合は、お気軽にコメントをお寄せください:)

EDIT2

おそらく、MPI と完全に統合された最適なスケーリングの問題は、経験に基づく Pi の推定です。

一辺の長さが 1 の正方形の内側に半径 1 の四分円をイメージすると、正方形にランダムな点を発射して Pi を推定し、それらが四分円の内側にあるかどうかを計算できます。

注: これは、[0, 1] 内の x,y でタプル (x,y) を生成し、これらのうち x² + y² <= 1 がいくつあるかを測定することと同じです。

Pi はおおよそ次のようになります。

4 * Points in Circle / total Points

MPI では、すべてのスレッドから生成された比率を収集するだけで済みます。これはオーバーヘッドがほとんどないため、クラスターの概念問題を完全に証明できます。

于 2013-03-08T18:55:44.797 に答える
2

他のコンピューティング パラダイムと同様に、分散メモリ プログラミングで使用される特定の確立されたパターンがあります。そのようなパターンの 1 つは、"bag of jobs" または "controller/worker" です (以前は "master/slave" と呼ばれていましたが、現在はこの名前は政治的に正しくないと見なされています)。次の理由から、あなたのケースに最適です。

  • 適切な条件下では、ワーカーの数に応じてスケーリングします。
  • 実装は簡単です。
  • 負荷分散機能が組み込まれています。

基本的な前提は非常に単純です。「コントローラー」プロセスにはジョブの大きなテーブル/キューがあり、実質的に 1 つの大きなループ (おそらく無限ループ) を実行します。「ワーカー」プロセスからのメッセージをリッスンし、応答します。最も単純なケースでは、ワーカーはジョブ リクエストまたは計算結果の 2 種類のメッセージのみを送信します。したがって、コントローラ プロセスは、ジョブ記述または終了要求の 2 種類のメッセージを送信します。

そして、このパターンの標準的で自明でない例は、マンデルブロ集合の彩色です。最終的な画像の各ピクセルの計算は、他のピクセルとは完全に独立して行われるため、遅延が大きく低速なネットワーク接続 (GigE など) を使用するクラスターでも非常にうまくスケーリングされます。極端な場合、各ワーカーは 1 つのピクセルを計算できますが、通信のオーバーヘッドが非常に高くなるため、画像を小さな四角形に分割することをお勧めします。マンデルブロー集合を彩る既製の MPI コードが多数あります。たとえば、このコードは行分割を使用します。つまり、1 つのジョブ アイテムで最終イメージの 1 行を埋めます。MPI プロセスの数が多い場合、かなり大きな画像サイズが必要になります。そうしないと、負荷が十分に分散されません。

MPI には、追加のプロセスを生成したり、外部で開始されたジョブをクライアント/サーバー方式で接続したりできるメカニズムもあります。それらを実装するのはロケット科学ではありませんが、インターコミュニケーターなどの高度な MPI の概念をある程度理解する必要があるため、ここでは省略します。

于 2013-03-09T09:46:37.213 に答える