25

マルチコア プログラミングに関する最近の話題で、MPIを使用する可能性を探っている人はいますか?

4

7 に答える 7

69

私は、マルチコア ノードを持つ大規模なクラスターで MPI を広範囲に使用してきました。単一のマルチコア ボックスに適しているかどうかはわかりませんが、コードがいつか単一のチップよりも大きくなると予想される場合は、MPI での実装を検討してください。現在、MPI よりも大きなスケールのものはありません。許容できないオーバーヘッドについて言及している投稿者がどこから来たのかはわかりませんが、関連するトレードオフの概要を以下に示してみました。詳細をお読みください。

MPI は、大規模な科学計算のデファクト スタンダードであり、マルチコア マシンですでに広く使用されています。とても速いです。最新のトップ 500 リストをご覧ください。そのリストの上位のマシンには、場合によっては数十万のプロセッサがあり、マルチソケットのデュアルおよびクアッドコア ノードが搭載されています。これらのマシンの多くは、非常に高速なカスタム ネットワーク (トーラス、メッシュ、ツリーなど) と、ハードウェアを認識する最適化された MPI 実装を備えています。

シングル チップのマルチコア マシンで MPI を使用する場合は、問題なく動作します。実際、最近のバージョンの Mac OS X にはOpenMPIがプリインストールされており、通常のマルチコア Linux マシンにインストールされた OpenMPI を簡単にダウンロードできます。OpenMPI は、Los Alamosのほとんどのシステムで使用されています。 LivermoreはLinux クラスターでmvapichを使用しています。本題に入る前に覚えておくべきことは、MPI は分散メモリシステムで大規模な科学的問題を解決するために設計されたということです。扱っているマルチコア ボックスには、おそらく共有メモリがあります。

OpenMPI およびその他の実装では、デフォルトでローカル メッセージ パッシングに共有メモリが使用されるため、メッセージをローカル プロセスに渡すときにネットワーク オーバーヘッドを心配する必要はありません。それは非常に透明性が高く、他の投稿者がオーバーヘッドの高さについてどこに懸念を抱いているのかわかりません。注意点として、MPI は単一のマルチコア ボックスで並列処理を実現するために使用できる最も簡単なものではないということです。MPI では、すべてのメッセージ パッシングが明示的です。このため、並列プログラミングの「アセンブリ言語」と呼ばれています。経験豊富なHPC担当者でない場合、プロセス間の明示的な通信は容易ではありません。また、共有メモリ ( UPC、OpenMP、Erlangなど) を最初に試すことができます。

解決するために複数のマシンが必要になる可能性のある並列アプリケーションを作成することが予想される場合は、MPI を使用することをお勧めします。通常のマルチコア ボックスで問題なくテストおよび実行できます。クラスターへの移行は、そこで機能するようになると、非常に簡単になります。単一のマシンしか必要としないアプリケーションを作成している場合は、別の方法を試してください。この種の並列処理を利用する簡単な方法があります。

最後に、本当に冒険したい場合は、MPI をスレッド、OpenMP、またはその他のローカル共有メモリ パラダイムと組み合わせて試してみてください。分散メッセージ パッシングには MPI を使用し、ノード上の並列処理には別のものを使用できます。これは、大型マシンが向かうところです。数十万以上のプロセッサを搭載した将来のマシンは、すべてのコアではなくすべてのノードにスケーリングする MPI 実装を持つことが予想され、HPC 担当者はハイブリッド アプリケーションの構築を余儀なくされるでしょう。これは気弱な人向けではなく、この分野で受け入れられるパラダイムができるまでには、やるべきことがたくさんあります。

于 2008-12-12T16:17:56.223 に答える
12

私はtgamblinに同意する必要があります。MPIを使用するには、おそらく袖をまくり上げてコードを掘り下げ、メッセージの編成を明示的に処理する必要があります。これがあなたの好きなこと、または気にしないことである場合、MPIは分散クラスターの場合と同じようにマルチコアマシンでも機能すると思います。

個人的な経験から言えば...私は大学院でいくつかのCコードをコーディングして、各ノード自体がマルチコアマシンであるクラスター上で電気生理学的モデルの大規模なモデリングを行いました。したがって、この問題に取り組むために私が考えたいくつかの異なる並列方法がありました。

1）MPIを単独で使用して、一部のプロセッサが同じマシン上でグループ化されている場合でも、すべてのプロセッサを独自の「ノード」として扱うことができます。

2）MPIを使用してマルチコアノード間を移動するデータを処理し、プロセッサがメモリを共有する各マルチコアマシン内でスレッド（POSIXスレッド）を使用できます。

私が取り組んでいた特定の数学的問題については、最初に1つのマルチコアマシンで2つの定式化をテストしました。1つはMPIを使用し、もう1つはPOSIXスレッドを使用します。結局のところ、MPIの実装ははるかに効率的であり、スレッド化された実装の1.3〜1.4とは対照的に、デュアルコアマシンでは2に近いスピードアップが得られました。MPIコードの場合、プロセッサがアイドル状態になることはめったになく、メッセージがプロセッサ間で受け渡される間ビジー状態を維持し、データ転送による遅延の多くをマスクするように操作を整理することができました。スレッド化されたコードでは、他のスレッドが計算を完了する間、スレッドが頻繁に座って待機することを余儀なくされる多くのミューテックスのボトルネックに陥りました。スレッド間で計算負荷のバランスを保つことは、この事実を助けるようには見えませんでした。

これは、私が取り組んでいたモデルだけに固有のものであった可能性があり、他のタイプの並列問題では、スレッド化とMPIの有効性が大きく異なる可能性があります。それにもかかわらず、私はMPIが扱いにくいオーバーヘッドを持っていることに同意しません。

于 2009-01-17T01:27:59.870 に答える
4

いいえ、私の意見では、マルチコア システムで行うほとんどの処理には適していません。オーバーヘッドが高すぎます。渡すオブジェクトは深く複製する必要があり、大きなオブジェクト グラフを渡して非常に小さな計算を実行するのは非常に非効率的です。これは、別々のプロセス間でデータを共有するためのものであり、ほとんどの場合、別々のメモリ空間で実行され、ほとんどの場合、長い計算を実行します。
マルチコア プロセッサは共有メモリ マシンであるため、オブジェクトのコピーを伴わず、ほとんどのスレッドが非常に短い時間実行される、並列処理を実行するはるかに効率的な方法があります。たとえば、マルチスレッドのクイックソートについて考えてみてください。メモリを割り当ててデータをスレッドにコピーしてからパーティション化するオーバーヘッドは、MPI と無制限のスレッドでははるかに遅くなります。シングル プロセッサで実行されている Quicksort よりも多くのプロセッサを使用できます。
例として、Java では、BlockingQueue (共有メモリ コンストラクト) を使用して、スレッド間でオブジェクト参照をほとんどオーバーヘッドなしで渡します。
その場所がないわけではありません。たとえば、メッセージ パッシングを使用する Google 検索クラスターを参照してください。しかし、それはおそらくあなたが解決しようとしている問題ではありません。

于 2008-09-29T08:10:33.550 に答える
1

私は個人的にErlangを取り上げました（そして私はこれまでのところ好きです）。メッセージベースのアプローチは問題のほとんどに当てはまるようで、それがマルチコアプログラミングの重要な項目の1つになると思います。私はMPIのオーバーヘッドについて知りませんでした、そしてそれを指摘してくれてありがとう

于 2008-09-29T09:13:36.397 に答える
1

MPI には、主にプロセス間通信と異種システムを処理するために、非常に大量のオーバーヘッドがあります。少量のデータが渡される場合や、データに対する計算の比率が大きい場合に使用しました。これは、ほとんどのコンシューマまたはビジネス タスクの典型的な使用シナリオではありません。いずれにせよ、以前の回答で述べたように、マルチコア マシンのような共有メモリ アーキテクチャでは、メモリ ポインタなど、それを処理するための非常に高速な方法があります。

上記のプロパティに何らかの問題があり、自分と同じ高速ネットワーク上にある必要がある他のマシンにジョブを分散できるようにしたい場合は、MPI が理にかなっている可能性があります。ただ、そのようなシナリオを想像するのは難しいです。

于 2008-09-29T08:29:37.547 に答える
0

低レベルのスレッド化が必要か、高レベルのスレッド化が必要かを決定する必要があります。低レベルが必要な場合は、pThread を使用します。競合状態を導入したり、スレッドのパフォーマンスが低下したりしないように注意する必要があります。

スケーラブルでタスクのスケジューリングを最適化する (C および C++) 用の OSS パッケージをいくつか使用しました。TBB (スレッド ビルディング ブロック) と Cilk Plus は優れており、コーディングが簡単で、地面のアプリケーションを取得できます。また、必要に応じて後で他のスレッド技術を統合するのに十分な柔軟性があると信じています (OpenMP など)。

www.threadingbuildingblocks.org www.cilkplus.org

于 2012-12-12T17:49:19.900 に答える