- 1 名前：デフォルトの名無しさん [2006/01/18(水) 08:31:11 ]
- 最近のCPUはマルチコアが技術トレンドになっています。
それに伴い、ソフトウェアは並列化というパラダイムシフトが
求められています。効率のよく並列化を実現するためにはアル
ゴリズムやデータ構造といった部分を根本から見直す必要が
あります。しかし、トレンドができてからあまり時間が経って
ないため、そいういったノウハウが蓄積されていません。
そこで、マルチコアを生かすためのソフトウェア設計というのは
どういうものか？という議論をするためのスレッドを立てました。
ソフトウェアの並列化に対して考えのある人や、インターネット
上のリソース、論文等があればどんどん書き込んだりリンクを
貼ってください。
【関連スレ】
OpenMPプログラミング
pc8.2ch.net/test/read.cgi/tech/1102483474/l50
- 266 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 00:25:24 ]
- >>265
それが新しいノウハウだろｗ
PS2 のころから Vu0 マイクロコード動かしてた連中にとっては、今までの延長だろうけど
- 267 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 01:12:40 ]
- ８６系ってＣＰＵの思想があれだから、マルチコア化を困難にさせてるんだよな・・・
- 268 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 01:20:43 ]
- ↑
こういう知ったかがわくのはどうにかならないのか？
- 269 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 01:22:39 ]
- >>267
思想がアレなのはiApx432だろ。
- 270 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 01:24:49 ]
- レジスタが専業化されてるってやつだろ？
今でこそ区別無く使えるようになったけど、それでもニーモニック汚過ぎ。
- 271 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 10:15:02 ]
- uOp fusion のコストが高すぎるといってるのか？
俺には的外れに思えるが。
- 272 名前：デフォルトの名無しさん mailto:sage [2006/03/24(金) 05:57:20 ]
- ↑
こういう知ったかがわくのはどうにかならないのか？
- 273 名前：デフォルトの名無しさん mailto:sage [2006/03/24(金) 11:57:44 ]
- 267が論旨を明確にすればいいだけの話。
- 274 名前：デフォルトの名無しさん mailto:sage [2006/03/24(金) 17:50:04 ]
- デコーダが複雑になるから、メニイコアでかつ個々のコアの
処理速度も上げるってのがやりにくいんじゃない？
という意味だと漏れは思う。
- 275 名前：デフォルトの名無しさん mailto:sage [2006/03/24(金) 22:46:44 ]
- つまりメタセコイアは生きた化石だということか。
- 276 名前：デフォルトの名無しさん [2006/05/14(日) 23:36:57 ]
- 鯖側は、簡単というか今まで通りでよいが、
クライアント側は大変だな。
- 277 名前：デフォルトの名無しさん mailto:sage [2006/05/14(日) 23:54:33 ]
- そうでもない
- 278 名前：デフォルトの名無しさん mailto:sage [2006/09/10(日) 14:07:50 ]
- ho
- 279 名前：デフォルトの名無しさん mailto:sage [2006/09/10(日) 20:48:00 ]
- >>276
2-4 並列くらいでいいんだから余裕じゃ。
大変って言ってる奴が居たら、それは「ﾏﾝﾄﾞｸｾ」って意味か、「もっと金寄越せ」って
意味かのどちらか。
- 280 名前：デフォルトの名無しさん mailto:sage [2006/09/15(金) 00:56:12 ]
- Objective-C + Cocoa なソースで OpenMP って使えるの??
- 281 名前：デフォルトの名無しさん mailto:sage [2006/09/30(土) 23:13:10 ]
- Cilkってどう？
- 282 名前：デフォルトの名無しさん mailto:sage [2006/09/30(土) 23:34:11 ]
- ｲｿﾃﾙが発表した４コアってプログラミング的にはどうなん？
性能を活かせるコンパイラってあるの？
- 283 名前：デフォルトの名無しさん mailto:sage [2006/10/01(日) 00:38:46 ]
- 80コアか・・・
機械的に最適化できる方法あるのかな？
ttp://techon.nikkeibp.co.jp/article/NEWS/20060927/121563/?ST=edaonline&ref=rss
- 284 名前：デフォルトの名無しさん mailto:sage [2006/10/03(火) 09:41:30 ]
- まぁ数年間は OpenMP 使ってチマチマ並列化するのが手っ取り早いだろーね。
でも 80 コアの時代には言語レベルで並列化/分散処理をサポートした
新しい言語が主流になってると思う。
そうじゃないとプログラミングがしんどくなるね。
- 285 名前：デフォルトの名無しさん mailto:sage [2006/10/08(日) 15:44:34 ]
- そこまでしてx86である必要がないような。
- 286 名前：デフォルトの名無しさん mailto:sage [2006/10/08(日) 19:56:41 ]
- 互換性が重要だからね。
x86系は（PC/AT互換機が業界標準になったおかげで）業界標準になったから過去の互換性切れないんだよ。
- 287 名前：デフォルトの名無しさん mailto:sage [2006/10/08(日) 22:54:13 ]
- ソースレベルで保持運用されてるUNIXなら、CPUの互換性なんて関係無いのにね。
- 288 名前：デフォルトの名無しさん mailto:sage [2006/10/08(日) 23:29:37 ]
- そういうわけに行かない業界と素人と過去の遺産の都合を考えろってこと。
カーネルやドライバ部分なんかはCPU変わったらほぼ完全に書き直しだろうし。
CPUごとに使用するコンパイラ＆ミドルウェアが変わることで開発やサポートのコストは跳ね上がる。
(商用ソフトがほとんどの場合ライセンス上の理由でソースコード公開できないことくらいは分かってると思うけど)
- 289 名前：288 mailto:sage [2006/10/08(日) 23:32:09 ]
- ×公開
○開示
だな。まぁ公開も商用である限りまず望めないだろうね。
- 290 名前：デフォルトの名無しさん mailto:sage [2006/10/09(月) 00:12:55 ]
- 倒産したソフト会社のプログラム使ってるわけでもあるまいて
その会社がコンパイルし直せば済む事をチマチマとw
- 291 名前：デフォルトの名無しさん mailto:sage [2006/10/09(月) 00:29:27 ]
- >>290
ユーザーが増えないから売れそうもないので対応しない
バイナリが流通しないから新しいアーキテクチャのユーザが増えない
以下繰り返し
この悪循環が始まるだけなんでそういう事を言われても困る。
- 292 名前：デフォルトの名無しさん mailto:sage [2006/10/10(火) 01:06:52 ]
- 「対応しないと売れない」の間違いじゃね？
つか、対応せずに済むというのはユーザー側の思考で、本来なら企業のビジネスチャンスのためにも積極的にハードウェアアーキテクチャを変更するべきなんだよ。
儲かるのはマイクロソフトだけ。っていう図式が何を意味しているかしっかりと考えてみろ。
- 293 名前：デフォルトの名無しさん mailto:sage [2006/10/12(木) 15:26:01 ]
- OpenMPは全然性能が出ないとか書いてあるページがあるけど、どうなのかなあ。
適切に大きな粒度でやれば、スケールしないはずが無いと思うんだけど・・・
- 294 名前：デフォルトの名無しさん mailto:sage [2006/10/12(木) 21:35:46 ]
- >>293
それは使い方間違ってるだけだろ。
俺が反論してやるからURLｷﾎﾞｿ
- 295 名前：デフォルトの名無しさん mailto:sage [2006/11/18(土) 02:08:28 ]
- そいつの考え方がおかしいんじゃねーのかどこか知らんが
- 296 名前：デフォルトの名無しさん mailto:sage [2006/11/26(日) 14:08:24 ]
- >>290
コンパイルできれば、そしてできたバイナリが予想通りの挙動を示してくれればいいんだけどね。
- 297 名前：デフォルトの名無しさん mailto:sage [2006/11/26(日) 14:41:15 ]
- 挙動不審
- 298 名前：デフォルトの名無しさん [2006/11/26(日) 22:38:34 ]
- マルチコアって何で難しいの？同期処理も必要なの以外はvolatille宣言しとけばいいんじゃないの？
あるいはSETI@homeみたいに部分に分けて処理させるのはどうなの？
あとマルチコアって確率論とか統計学とかいるの？（学問ではなにが関係するの？）
というか今までもスパコンはほとんどマルチコアだと思うけどあれはなんで問題なく高速化できてるの？
- 299 名前：デフォルトの名無しさん [2006/11/26(日) 22:45:47 ]
- volatile最強宣言ｋｔｋｒ
- 300 名前：デフォルトの名無しさん [2006/11/26(日) 22:53:22 ]
- > マルチコアって何で難しいの？同期処理も必要なの以外はvolatille宣言しとけばいいんじゃないの？
釣りですか？
> あとマルチコアって確率論とか統計学とかいるの？（学問ではなにが関係するの？）
プロセス代数という数学。プロセス代数にはSP、π計算、CCSなどがある。
> というか今までもスパコンはほとんどマルチコアだと思うけどあれはなんで問題なく高速化できてるの？
分散処理の研究が進んでいるのと、それ様のプラットフォーム(MPIとか)が
整備されているから。何も考えずに無為にやっているけど大丈夫なわけでない。
- 301 名前：デフォルトの名無しさん [2006/11/26(日) 22:54:32 ]
- 訂正
> プロセス代数という数学。プロセス代数にはSP、π計算、CCSなどがある。
↓
> プロセス代数という数学。プロセス代数にはCSP、π計算、CCSなどがある。
- 302 名前：デフォルトの名無しさん mailto:sage [2006/11/26(日) 23:10:00 ]
- ヘテロ環境での最適配置戦略とか
reconfigurableなLSIを活用するとか
学者さんは嫌いそうだが必要になりそう
- 303 名前：デフォルトの名無しさん mailto:sage [2006/12/20(水) 00:38:23 ]
- おお、こんなスレが。
並列プログラム用のライブラリを作成しています。（C++/Unix用）
pards.sourceforge.jp/
よろしければ御意見下さい。
>>166 の人のお望みの通り、SPAWN(foo());とすると関数fooを並列に実行します。
スレッドじゃなくてプロセスだけど。
プロセス間の通信、同期はSync<int> a;のように宣言した変数に対して、
a.write(1), a.read() のようにすることで行います。readはwriteが終わるまで
ブロックします。
実用的な例として、bzip2の並列化も行っています。
詳しくは上記URLをご参照下さい。宣伝失礼致しました。
- 304 名前：デフォルトの名無しさん mailto:sage [2006/12/20(水) 00:53:18 ]
- sureddo版を作る気はないのかえ？
- 305 名前：303 mailto:sage [2006/12/20(水) 01:14:41 ]
- スレッド版？ >>304
スレッドはデフォルトで全メモリ領域をシェアするので、デバッグ困難なバグの
温床になっているという主張なのですよ > このライブラリ
グローバル変数触るだけでMT-unsafeになるので、スレッドを使った
既存のプログラムの並列化は難しいのですが、プロセスはメモリ空間を
分けるので、そんなことは無いと。
もちろんその分オーバヘッドはあるのですが、最近のOSなら我慢できる範囲では
無いかと思います。
# とか言いながらスレッド版作ったりして
- 306 名前：デフォルトの名無しさん mailto:sage [2006/12/20(水) 02:09:16 ]
- なるほろ。
コードはそのままで、
デバッグ中は別プロセス、リリース時はスレッドで実行できるとかだと
超カッコＥかもしれませんな。
ぬー、でもあんまり差が出ない気がしてきた。
- 307 名前：デフォルトの名無しさん mailto:sage [2006/12/20(水) 18:23:59 ]
- >>303
ネットワーク越しあり？
- 308 名前：デフォルトの名無しさん [2006/12/20(水) 23:21:00 ]
- あら、すごいと思ったけど、やはりその筋の研究をされている方ですか。
実際にどれだけパフォーマンスに差がでるかわからないけど、
スレッド版を用意してくれると実際に使う人がベンチマークが取れて
プロセス版かスレッド版かどちらかを選択するか判断できていいですな。
> スレッドはデフォルトで全メモリ領域をシェアするので、デバッグ困難なバグの
> 温床になっているという主張なのですよ > このライブラリ
さすがに含蓄のあるお言葉ですな。
- 309 名前：303 mailto:sage [2006/12/20(水) 23:28:00 ]
- >>307
いや、SMPだけを対象にしてます。
MPC++/SCoreとか、ネットワークで接続されたコンピュータを
SMPに見せるのもあるけど、あそこまで作るのは大変っすよ(^^;
- 310 名前：デフォルトの名無しさん mailto:sage [2006/12/21(木) 19:53:02 ]
- JAVAってマルチCPUやマルチコアでも恩恵が無いって
昔は言ってたが今は変わったのか？
- 311 名前：デフォルトの名無しさん [2006/12/21(木) 20:09:14 ]
- >>310
JAVAはマルチスレッドにしても速度は上がらんよ。
- 312 名前：デフォルトの名無しさん [2006/12/21(木) 22:00:09 ]
- >>310
速度を気にするならJAVAは問題外
- 313 名前：デフォルトの名無しさん [2006/12/21(木) 23:29:59 ]
- てっきり >>194 みたいなことが書いてあるから…
.netは対応？済みらしいがマルチコア環境じゃないから試せない。
- 314 名前：デフォルトの名無しさん mailto:sage [2006/12/22(金) 00:01:18 ]
- マルチスレッドは速度を向上させるのが目的ではないと思うがなあ
- 315 名前：デフォルトの名無しさん mailto:sage [2006/12/22(金) 00:09:25 ]
- サーバ的に言えばスループットを多重化に影響されず一定とするためのものだわな。
XMLのパースとその他みたいなパイプライン？は既にやってるとこもあるみたいだけど。
- 316 名前：デフォルトの名無しさん mailto:sage [2006/12/22(金) 00:10:31 ]
- >>310-313
AP レイヤで使うのに十分なくらいならスケールするがな。
マルチノード、マルチインスタンスにはした方が良いけど、
かなりの大規模ノードじゃなければ十分。
- 317 名前：デフォルトの名無しさん mailto:sage [2006/12/22(金) 04:56:33 ]
- >>285
x86である必要があってx86なのではなく、
数が出ているx86のコストパフォーマンスが優れているからx86なのだと思う。
- 318 名前：デフォルトの名無しさん mailto:sage [2006/12/22(金) 05:05:09 ]
- >>314
何が目的なのか、ハッキリ言ってよ。
>>316
クライアントが同時に複数いる状況で性能を要求されるサーバならば、
2コアとか4コアくらいなら、
同期する必要のない部分と同期する必要がある部分に分けるだけで、
十分だったりするしね。
>>315
XMLのパースなんかは、他のスレッドと同期する必要がない処理なので、
パイプラインにするよりも、普通にスレッドプーリングでいいでしょう。
- 319 名前：デフォルトの名無しさん mailto:sage [2006/12/22(金) 12:35:22 ]
- >>310
他の言語と同じように恩恵はあるよ。
恩恵がないのは遥か昔の green thread の頃かな。
- 320 名前：デフォルトの名無しさん [2007/02/14(水) 06:21:12 ]
- Intel，80コアでTFLOPSを実現する浮動小数点演算プロセッサ開発
ttp://www.4gamer.net/news.php?url=/news/history/2007.02/20070213183701detail.html
- 321 名前：デフォルトの名無しさん mailto:sage [2007/03/06(火) 16:26:58 ]
- トイレで大きい方をして席に戻ってきたら、周りの席の同僚女3人に大笑いされた。
職場の女がニコニコしながら、
「上司の○○さんが呼んでいたので『地球の平和を守りにいってます！』と答えておきましたよ〜」
死にたい気持ちになった。
- 322 名前：デフォルトの名無しさん mailto:sage [2007/03/06(火) 16:32:41 ]
- へたくそなコピペじゃねーぞ！
あまりにショックなので、こんな過疎スレに書き込んでいる。
今夜は一人で飲みたい。
- 323 名前：デフォルトの名無しさん mailto:sage [2007/03/06(火) 16:38:00 ]
- ↓あまりに悔しいから、お前のあだ名は「ウンコマン」にしてやる！
- 324 名前：デフォルトの名無しさん mailto:sage [2007/03/06(火) 16:47:30 ]
- オッス、オラうんこまん！
地球防衛隊員ってのをやってるんだ。よろしくな！
- 325 名前：デフォルトの名無しさん [2007/03/06(火) 16:57:41 ]
- >>324
恥ずかしい自演乙
- 326 名前：デフォルトの名無しさん mailto:sage [2007/03/07(水) 01:42:39 ]
- >>321
なんじゃそのFFやらDQの発売日翌日に遅刻した予備校生の言い訳みたいなのは。
- 327 名前：デフォルトの名無しさん [2007/03/13(火) 14:25:23 ]
- それより昼に仏跳麺を食った後に目薬を買おうとミドリ薬品に寄ったら会社の山下
さん（結構かわいい）がレジで支払いしてるトコだった。そのレジ台に置いてあったの
がイチジク浣腸の１０個入りパッケージ。もう裕子ちゃんがお尻にイチジク浣腸を入
れてるのを想像して今も勃起しっぱなし。このことは会社の同僚にはだまってる。
噂を流したら俺だってわかるし山下さんもかわいそうだから。
- 328 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 01:14:45 ]
- 動画エンコってマルチスレッド化するより単純にコアの数だけ時間か容量で等分して
それぞれエンコさせたファイルをつなぎ合わせた方が速そうな気がするけど、結局は>>106,115,209なの？
- 329 名前：デフォルトの名無しさん [2007/03/20(火) 22:13:18 ]
- linuxでやれ。
- 330 名前：デフォルトの名無しさん mailto:sage [2007/03/21(水) 15:28:42 ]
- やってみる価値は非常にありそうだな。
- 331 名前：デフォルトの名無しさん mailto:sage [2007/03/21(水) 16:43:18 ]
- つなぎ目ってどうするんだろう
mpegでいうIフレームにすればいいだけ？
- 332 名前：デフォルトの名無しさん mailto:sage [2007/03/21(水) 20:02:48 ]
- >>331
たぶんそうなんじゃない。
動画は前の画像の圧縮して解凍したものを使うから
ある程度の時間の動画をひとつのスレッドにしたほうが
効果ある上に作るのがとても楽だね。
- 333 名前：デフォルトの名無しさん mailto:sage [2007/03/21(水) 21:17:47 ]
- キャッシュ効率が下がるんじゃない？
- 334 名前：デフォルトの名無しさん mailto:sage [2007/03/21(水) 21:47:44 ]
- 下がるだろうね。
キャッシュ重視で1枚の画像を複数のスレッドでMPEG圧縮する。
手間かける余裕があるかどうか。
CPUのマルチコア化を一般ユーザが使うようになるころは
メモリとかHDDの性能はどうなるのかしら。
- 335 名前：デフォルトの名無しさん mailto:sage [2007/03/21(水) 22:43:12 ]
- エンコードに必要なワーキングセットをＮとすると
総キャッシュ量/Nより多いスレッド数でやると効率下がるだけやね
・・・そこまでやるか？
- 336 名前：デフォルトの名無しさん mailto:sage [2007/03/22(木) 03:49:20 ]
- ここだと一般論を装った妄想でお茶を濁されがちだから
Core2限定の専用スレ立てていい？
- 337 名前：デフォルトの名無しさん mailto:sage [2007/03/22(木) 11:25:18 ]
- ダンゴ様の許可があればいい
- 338 名前：デフォルトの名無しさん mailto:sage [2007/03/22(木) 14:28:33 ]
- >>336
Xeonは除外?
- 339 名前：デフォルトの名無しさん mailto:sage [2007/03/23(金) 02:25:42 ]
- >>336
どんな話がどう濁されているのか具体的に。
そもそも過疎ってるんだしスレを良い方向に変えていくのも一つ。
>>338
XeonもCore2ファミリじゃね?
- 340 名前：デフォルトの名無しさん mailto:sage [2007/03/23(金) 02:55:13 ]
- 初期のXeonもCore2だっけ?
- 341 名前：デフォルトの名無しさん mailto:sage [2007/03/23(金) 03:15:39 ]
- ダンゴ的にはどうよ？
- 342 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 00:56:14 ]
- 結局は高クロックのシングルコアが速い？
- 343 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 04:29:47 ]
- それができないからthe free lunch is overなのでは？
- 344 名前：デフォルトの名無しさん [2007/03/29(木) 20:44:06 ]
- Core2は使うレジスタ数を減らせば速いとかどっかで見たんですが
どういうことでしょうか
Pen3やNetBurst系とは逆？
- 345 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:00:33 ]
- この質問はダンゴじゃないとマトモに返答できないと見た
- 346 名前：・∀・）っ-○◎● mailto:sage [2007/03/30(金) 01:52:36 ]
- .
- 347 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 03:33:19 ]
- 32bitモード、つまり
増えたレジスタを活かさないモードなら速い、ということなら
皆知ってるけどね。
- 348 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 22:22:50 ]
- 人間活動 → スカラ
自然現象 → ベクトル
中途半端 → 今のCMP全般
- 349 名前：デフォルトの名無しさん [2007/04/03(火) 09:13:21 ]
- ＿＿＿_
／⌒ ⌒＼ ﾎｼﾞﾎｼﾞ
／（ ●） （●）＼
／::::::⌒（__人__）⌒::::: ＼ ＜で？
| ｍj |ー'´ |
＼ 〈＿_ﾉ ／
ノ ﾉ
- 350 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 19:26:14 ]
- おちんぽ
- 351 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 21:20:44 ]
- 結局、下手に最適化せずに、単純なバイナリで、プロセッサに条件予測させた方が速いってことか。
- 352 名前：デフォルトの名無しさん mailto:sage [2007/04/15(日) 03:08:29 ]
- 既出かもしれんけど
cag.csail.mit.edu/ps3/index.shtml
- 353 名前：デフォルトの名無しさん [2007/05/06(日) 00:35:15 ]
- JCSPの話はここでいいのか？
- 354 名前：デフォルトの名無しさん mailto:sage [2007/05/06(日) 02:41:23 ]
- 良いんじゃない。
Java 固有の質問だったら Java のスレでやった方が良いかもしれないけどね。
- 355 名前：デフォルトの名無しさん [2007/06/03(日) 02:01:31 ]
- 保守
- 356 名前：デフォルトの名無しさん [2007/06/03(日) 15:31:56 ]
- 逐次処理を並列処理に分割する手法で代表的なものって何？
- 357 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 15:33:02 ]
- OpenMP とか関数型言語で書き直すとか？
- 358 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 15:41:12 ]
- >>356
OpenMP、pthread、MPI 辺りですかね。
# SMP 環境でわざわざ MPI する人も少ないかもしれませんが。
ちなみに性能的には MPI > pthread > OpenMP、
お手軽さでは OpenMP > pthread > MPI の順でしょうか。
- 359 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 16:43:38 ]
- >>358
>ちなみに性能的には MPI > pthread > OpenMP、
ええっ!? SMP環境でMPIってpthreadより性能いいの?
- 360 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 17:47:44 ]
- OpenMP、pthread、MPI ってどこにあるの？
- 361 名前：デフォルトの名無しさん mailto:sage [2007/06/03(日) 18:15:19 ]
- 一番星を右に進んだ所、虹の彼方に
- 362 名前：デフォルトの名無しさん [2007/06/04(月) 19:05:59 ]
- ジョブを並列に分割する際に、何に注目して並列化すればよいのでしょう？
データですか？タスクですか？
- 363 名前：デフォルトの名無しさん mailto:sage [2007/06/04(月) 19:20:07 ]
- 適材適所。
- 364 名前：デフォルトの名無しさん [2007/06/04(月) 19:22:08 ]
- 栄枯盛衰
- 365 名前：デフォルトの名無しさん mailto:sage [2007/06/06(水) 00:22:34 ]
- >>359
MPIは複数の計算ノード（例えばPCとか）を高速な通信回線で接続した
HPCクラスタ用ですね。
pthreadは共有メモリシステムじゃないと使えないので、CPUの数を増や
してもいくつかの理由（メモリアクセスの集中やキャッシュコヒーレンシ
維持のためのオーバーヘッド増加）のために、システム全体の性能はある
程度で飽和してします。大体 CPU 8〜16 個くらいが限界でしょうか。
クラスタシステムではCPUだけではなくメモリも分散配置しているので、
うまく仕事を複数のノードに配分するようにプログラムを作ることがで
きれば、もっとCPUを増やしてもシステム性能を向上させることができ
ます。
# でもそのソフトを作ったりデバッグするのが大変なので、MPIは暇な
# 学生が使える教育機関でしか人気が無いような気がする…。
- 366 名前：デフォルトの名無しさん mailto:sage [2007/06/06(水) 13:37:00 ]
- >>365
MPIが性能を十分に発揮するのは「高速な通信回線で接続したHPCクラスタ」での話ですよね
>>358
># SMP 環境でわざわざ MPI する人も少ないかもしれませんが。
>
>ちなみに性能的には MPI > pthread > OpenMP、
>お手軽さでは OpenMP > pthread > MPI の順でしょうか。
「SMP 環境でわざわざ MPI」してpthreadより性能を発揮する場面ってあるんでしょうか?
あるいは下から2行目の「MPI」っつてるのは「高速な通信回線で接続したHPCクラスタ」が前提と読むべきなんですかね?
|
 |
