【マルチコア】並列化 ..
247:デフォルトの名無しさん
06/02/12 23:55:41
OSがプリエンプティブであればマルチコアかどうかは
さほど問題ではないと思うのだがどうか。
248:デフォルトの名無しさん
06/02/13 00:18:59
>>247
それは必要条件であって十分条件じゃない。
そもそも何に対して問題無いって言ってる訳さ?
スケジューラがプリエンプティブに出来ていたら、カーネルが
ジャイアントロックしても問題無い?
大体、マルチコアつっても色々ある訳だが、どのマルチコアを
指して問題無いって言ってるんだ?
非対称コアなのか対称なのか、キャッシュは共有されている
のかいないのか、スレッディングはあるのか無いのか、それは
SMT なのか CGMT なのか FGMT なのか??
NUMA なマルチプロセッサとマルチコアじゃ最適化ポイントが
全然違うんだぜ。
それに、マルチコアは OS だけの問題じゃ無い。コンパイラは
CPU の実装を理解して最適化を掛けているのか、アプリは
MT でスケールするように作られているのか???
ネタ振りとしてはこれくらいで良いか?
249:デフォルトの名無しさん
06/02/13 10:57:19
シングルスレッド最強
250:デフォルトの名無しさん
06/02/13 20:52:13
シングルスレッドで作って、適当にexecすればいいじゃん。
何を悩んでいるのかわからない。
251:デフォルトの名無しさん
06/02/13 20:58:46
もう面倒くさいよ。
252:デフォルトの名無しさん
06/02/14 15:41:09
おわりか
253:デフォルトの名無しさん
06/02/23 13:09:55
URLﾘﾝｸ(japan.cnet.com)
Cell向けにOctopilerツールが発表されるらしい。
どういう形で支援するか謎だ。そのあたりの情報が外部にも出してもらえると、
今後のマルチコア向けアプリケーションの開発に少しは参考になりそう。
聞きかじりなんだけど、Cellってバス予約という機能があって、コアごとに
あらかじめ必要なバス帯域をキープできて、一度に複数のバスアクセスが
集中しないようにできているみたいだね。バス帯域の問題はどうにかして
欲しいけど、PCでは同様の解決方法は難しいかな？
仕事でCellとか触れる人はいいね。自分は関係ない職種だから触れません。
254:デフォルトの名無しさん
06/02/23 13:48:56
マルチコアでマルチスレッド処理が平気でできれば、これから食いぶちがありますあ？
255:デフォルトの名無しさん
06/02/23 14:21:45
なにやっても食っていける。重要なのは仕事取る（就職含む）対人スキル。
プログラミングはそれからだ。
とはいえ、金出す側の鼻が利く場合に備えて腕は磨いとけ
256:デフォルトの名無しさん
06/02/23 14:56:45
ドカタ乙
257:デフォルトの名無しさん
06/03/04 22:34:53
特に意味はないが、保守っとく。
ちょっと古いけど、Timed Calculus of Communicating Systems つーのを調査中。
258:デフォルトの名無しさん
06/03/06 22:39:39
保守
259:デフォルトの名無しさん
06/03/06 23:37:03
>>257
googleで検索したけど、TCCSって何ですか？TimedがつかないCCSなら
たくさん説明があるんですが、似たものもしくは同じものなんですかね。
Calculusいうぐらいだからπ計算とかの親戚の計算モデルっぽいのは
わかるんですが。
ここを読んでいる人でプロセス代数とかやってる人っています？
260:デフォルトの名無しさん
06/03/07 08:21:54
そりゃCCSなら説明がたくさんあるだろうな・・・
261:デフォルトの名無しさん
06/03/12 02:13:05
>>253
OpenMPのpragmaを流用するみたい
262:http://www.vector.co.jp/soft/win95/util/se072729.html
06/03/18 22:08:36
TextSS のWindowsXP(Professional)64bit対応化おながいします
もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
そういや64bitにネイティブ対応している２ｃｈブラウザてありましたっけ？
263:デフォルトの名無しさん
06/03/18 22:23:01
>>261
そうなんですか。できることは限定されているような気がしますが、
普通にCellに最適化されたプログラムを書くより大分楽にはなり
そうですね。
264:デフォルトの名無しさん
06/03/22 23:49:32
URLﾘﾝｸ(it.nikkei.co.jp)
やっぱり開発が難しいそうですよ。新しいノウハウが必要らしい。予想通りだ。
マルチコアはいいけどソフトウェアの負担は大きい。
265:デフォルトの名無しさん
06/03/23 00:22:34
86とか汎用の石のマルチコアが難しいというのと
Cellが難しいというのとはたぶん難しい場所が違う
CellはPS2の延長と考えればすっきりするしその程度
266:デフォルトの名無しさん
06/03/23 00:25:24
>>265
それが新しいノウハウだろｗ
PS2 のころから Vu0 マイクロコード動かしてた連中にとっては、今までの延長だろうけど
267:デフォルトの名無しさん
06/03/23 01:12:40
８６系ってＣＰＵの思想があれだから、マルチコア化を困難にさせてるんだよな・・・
268:デフォルトの名無しさん
06/03/23 01:20:43
↑
こういう知ったかがわくのはどうにかならないのか？
269:デフォルトの名無しさん
06/03/23 01:22:39
>>267
思想がアレなのはiApx432だろ。
270:デフォルトの名無しさん
06/03/23 01:24:49
レジスタが専業化されてるってやつだろ？
今でこそ区別無く使えるようになったけど、それでもニーモニック汚過ぎ。
271:デフォルトの名無しさん
06/03/23 10:15:02
uOp fusion のコストが高すぎるといってるのか？
俺には的外れに思えるが。
272:デフォルトの名無しさん
06/03/24 05:57:20
↑
こういう知ったかがわくのはどうにかならないのか？
273:デフォルトの名無しさん
06/03/24 11:57:44
267が論旨を明確にすればいいだけの話。
274:デフォルトの名無しさん
06/03/24 17:50:04
デコーダが複雑になるから、メニイコアでかつ個々のコアの
処理速度も上げるってのがやりにくいんじゃない？
という意味だと漏れは思う。
275:デフォルトの名無しさん
06/03/24 22:46:44
つまりメタセコイアは生きた化石だということか。
276:デフォルトの名無しさん
06/05/14 23:36:57
鯖側は、簡単というか今まで通りでよいが、
クライアント側は大変だな。
277:デフォルトの名無しさん
06/05/14 23:54:33
そうでもない
278:デフォルトの名無しさん
06/09/10 14:07:50
ho
279:デフォルトの名無しさん
06/09/10 20:48:00
>>276
2-4 並列くらいでいいんだから余裕じゃ。
大変って言ってる奴が居たら、それは「ﾏﾝﾄﾞｸｾ」って意味か、「もっと金寄越せ」って
意味かのどちらか。
280:デフォルトの名無しさん
06/09/15 00:56:12
Objective-C + Cocoa なソースで OpenMP って使えるの??
281:デフォルトの名無しさん
06/09/30 23:13:10
Cilkってどう？
282:デフォルトの名無しさん
06/09/30 23:34:11
ｲｿﾃﾙが発表した４コアってプログラミング的にはどうなん？
性能を活かせるコンパイラってあるの？
283:デフォルトの名無しさん
06/10/01 00:38:46
80コアか・・・
機械的に最適化できる方法あるのかな？
URLﾘﾝｸ(techon.nikkeibp.co.jp)
284:デフォルトの名無しさん
06/10/03 09:41:30
まぁ数年間は OpenMP 使ってチマチマ並列化するのが手っ取り早いだろーね。
でも 80 コアの時代には言語レベルで並列化/分散処理をサポートした
新しい言語が主流になってると思う。
そうじゃないとプログラミングがしんどくなるね。
285:デフォルトの名無しさん
06/10/08 15:44:34
そこまでしてx86である必要がないような。
286:デフォルトの名無しさん
06/10/08 19:56:41
互換性が重要だからね。
x86系は（PC/AT互換機が業界標準になったおかげで）業界標準になったから過去の互換性切れないんだよ。
287:デフォルトの名無しさん
06/10/08 22:54:13
ソースレベルで保持運用されてるUNIXなら、CPUの互換性なんて関係無いのにね。
288:デフォルトの名無しさん
06/10/08 23:29:37
そういうわけに行かない業界と素人と過去の遺産の都合を考えろってこと。
カーネルやドライバ部分なんかはCPU変わったらほぼ完全に書き直しだろうし。
CPUごとに使用するコンパイラ＆ミドルウェアが変わることで開発やサポートのコストは跳ね上がる。
(商用ソフトがほとんどの場合ライセンス上の理由でソースコード公開できないことくらいは分かってると思うけど)
289:288
06/10/08 23:32:09
×公開
○開示
だな。まぁ公開も商用である限りまず望めないだろうね。
290:デフォルトの名無しさん
06/10/09 00:12:55
倒産したソフト会社のプログラム使ってるわけでもあるまいて
その会社がコンパイルし直せば済む事をチマチマとw
291:デフォルトの名無しさん
06/10/09 00:29:27
>>290
ユーザーが増えないから売れそうもないので対応しない
バイナリが流通しないから新しいアーキテクチャのユーザが増えない
以下繰り返し
この悪循環が始まるだけなんでそういう事を言われても困る。
292:デフォルトの名無しさん
06/10/10 01:06:52
「対応しないと売れない」の間違いじゃね？
つか、対応せずに済むというのはユーザー側の思考で、本来なら企業のビジネスチャンスのためにも積極的にハードウェアアーキテクチャを変更するべきなんだよ。
儲かるのはマイクロソフトだけ。っていう図式が何を意味しているかしっかりと考えてみろ。
293:デフォルトの名無しさん
06/10/12 15:26:01
OpenMPは全然性能が出ないとか書いてあるページがあるけど、どうなのかなあ。
適切に大きな粒度でやれば、スケールしないはずが無いと思うんだけど・・・
294:デフォルトの名無しさん
06/10/12 21:35:46
>>293
それは使い方間違ってるだけだろ。
俺が反論してやるからURLｷﾎﾞｿ
295:デフォルトの名無しさん
06/11/18 02:08:28
そいつの考え方がおかしいんじゃねーのかどこか知らんが
296:デフォルトの名無しさん
06/11/26 14:08:24
>>290
コンパイルできれば、そしてできたバイナリが予想通りの挙動を示してくれればいいんだけどね。
297:デフォルトの名無しさん
06/11/26 14:41:15
挙動不審
298:デフォルトの名無しさん
06/11/26 22:38:34
マルチコアって何で難しいの？同期処理も必要なの以外はvolatille宣言しとけばいいんじゃないの？
あるいはSETI@homeみたいに部分に分けて処理させるのはどうなの？
あとマルチコアって確率論とか統計学とかいるの？（学問ではなにが関係するの？）
というか今までもスパコンはほとんどマルチコアだと思うけどあれはなんで問題なく高速化できてるの？
299:デフォルトの名無しさん
06/11/26 22:45:47
volatile最強宣言ｋｔｋｒ
300:デフォルトの名無しさん
06/11/26 22:53:22
> マルチコアって何で難しいの？同期処理も必要なの以外はvolatille宣言しとけばいいんじゃないの？
釣りですか？
> あとマルチコアって確率論とか統計学とかいるの？（学問ではなにが関係するの？）
プロセス代数という数学。プロセス代数にはSP、π計算、CCSなどがある。
> というか今までもスパコンはほとんどマルチコアだと思うけどあれはなんで問題なく高速化できてるの？
分散処理の研究が進んでいるのと、それ様のプラットフォーム(MPIとか)が
整備されているから。何も考えずに無為にやっているけど大丈夫なわけでない。
301:デフォルトの名無しさん
06/11/26 22:54:32
訂正
> プロセス代数という数学。プロセス代数にはSP、π計算、CCSなどがある。
↓
> プロセス代数という数学。プロセス代数にはCSP、π計算、CCSなどがある。
302:デフォルトの名無しさん
06/11/26 23:10:00
ヘテロ環境での最適配置戦略とか
reconfigurableなLSIを活用するとか
学者さんは嫌いそうだが必要になりそう
303:デフォルトの名無しさん
06/12/20 00:38:23
おお、こんなスレが。
並列プログラム用のライブラリを作成しています。（C++/Unix用）
URLﾘﾝｸ(pards.sourceforge.jp)
よろしければ御意見下さい。
>>166 の人のお望みの通り、SPAWN(foo());とすると関数fooを並列に実行します。
スレッドじゃなくてプロセスだけど。
プロセス間の通信、同期はSync<int> a;のように宣言した変数に対して、
a.write(1), a.read() のようにすることで行います。readはwriteが終わるまで
ブロックします。
実用的な例として、bzip2の並列化も行っています。
詳しくは上記URLをご参照下さい。宣伝失礼致しました。
304:デフォルトの名無しさん
06/12/20 00:53:18
sureddo版を作る気はないのかえ？
305:303
06/12/20 01:14:41
スレッド版？ >>304
スレッドはデフォルトで全メモリ領域をシェアするので、デバッグ困難なバグの
温床になっているという主張なのですよ > このライブラリ
グローバル変数触るだけでMT-unsafeになるので、スレッドを使った
既存のプログラムの並列化は難しいのですが、プロセスはメモリ空間を
分けるので、そんなことは無いと。
もちろんその分オーバヘッドはあるのですが、最近のOSなら我慢できる範囲では
無いかと思います。
# とか言いながらスレッド版作ったりして
306:デフォルトの名無しさん
06/12/20 02:09:16
なるほろ。
コードはそのままで、
デバッグ中は別プロセス、リリース時はスレッドで実行できるとかだと
超カッコＥかもしれませんな。
ぬー、でもあんまり差が出ない気がしてきた。
307:デフォルトの名無しさん
06/12/20 18:23:59
>>303
ネットワーク越しあり？
308:デフォルトの名無しさん
06/12/20 23:21:00
あら、すごいと思ったけど、やはりその筋の研究をされている方ですか。
実際にどれだけパフォーマンスに差がでるかわからないけど、
スレッド版を用意してくれると実際に使う人がベンチマークが取れて
プロセス版かスレッド版かどちらかを選択するか判断できていいですな。
> スレッドはデフォルトで全メモリ領域をシェアするので、デバッグ困難なバグの
> 温床になっているという主張なのですよ > このライブラリ
さすがに含蓄のあるお言葉ですな。
309:303
06/12/20 23:28:00
>>307
いや、SMPだけを対象にしてます。
MPC++/SCoreとか、ネットワークで接続されたコンピュータを
SMPに見せるのもあるけど、あそこまで作るのは大変っすよ(^^;
310:デフォルトの名無しさん
06/12/21 19:53:02
JAVAってマルチCPUやマルチコアでも恩恵が無いって
昔は言ってたが今は変わったのか？
311:デフォルトの名無しさん
06/12/21 20:09:14
>>310
JAVAはマルチスレッドにしても速度は上がらんよ。
312:デフォルトの名無しさん
06/12/21 22:00:09
>>310
速度を気にするならJAVAは問題外
313:デフォルトの名無しさん
06/12/21 23:29:59
てっきり >>194 みたいなことが書いてあるから…
.netは対応？済みらしいがマルチコア環境じゃないから試せない。
314:デフォルトの名無しさん
06/12/22 00:01:18
マルチスレッドは速度を向上させるのが目的ではないと思うがなあ
315:デフォルトの名無しさん
06/12/22 00:09:25
サーバ的に言えばスループットを多重化に影響されず一定とするためのものだわな。
XMLのパースとその他みたいなパイプライン？は既にやってるとこもあるみたいだけど。
316:デフォルトの名無しさん
06/12/22 00:10:31
>>310-313
AP レイヤで使うのに十分なくらいならスケールするがな。
マルチノード、マルチインスタンスにはした方が良いけど、
かなりの大規模ノードじゃなければ十分。
317:デフォルトの名無しさん
06/12/22 04:56:33
>>285
x86である必要があってx86なのではなく、
数が出ているx86のコストパフォーマンスが優れているからx86なのだと思う。
318:デフォルトの名無しさん
06/12/22 05:05:09
>>314
何が目的なのか、ハッキリ言ってよ。
>>316
クライアントが同時に複数いる状況で性能を要求されるサーバならば、
2コアとか4コアくらいなら、
同期する必要のない部分と同期する必要がある部分に分けるだけで、
十分だったりするしね。
>>315
XMLのパースなんかは、他のスレッドと同期する必要がない処理なので、
パイプラインにするよりも、普通にスレッドプーリングでいいでしょう。
319:デフォルトの名無しさん
06/12/22 12:35:22
>>310
他の言語と同じように恩恵はあるよ。
恩恵がないのは遥か昔の green thread の頃かな。
320:デフォルトの名無しさん
07/02/14 06:21:12
Intel，80コアでTFLOPSを実現する浮動小数点演算プロセッサ開発
URLﾘﾝｸ(www.4gamer.net)
321:デフォルトの名無しさん
07/03/06 16:26:58
トイレで大きい方をして席に戻ってきたら、周りの席の同僚女3人に大笑いされた。
職場の女がニコニコしながら、
「上司の○○さんが呼んでいたので『地球の平和を守りにいってます！』と答えておきましたよ〜」
死にたい気持ちになった。
322:デフォルトの名無しさん
07/03/06 16:32:41
へたくそなコピペじゃねーぞ！
あまりにショックなので、こんな過疎スレに書き込んでいる。
今夜は一人で飲みたい。
323:デフォルトの名無しさん
07/03/06 16:38:00
↓あまりに悔しいから、お前のあだ名は「ウンコマン」にしてやる！
324:デフォルトの名無しさん
07/03/06 16:47:30
オッス、オラうんこまん！
地球防衛隊員ってのをやってるんだ。よろしくな！
325:デフォルトの名無しさん
07/03/06 16:57:41
>>324
恥ずかしい自演乙
326:デフォルトの名無しさん
07/03/07 01:42:39
>>321
なんじゃそのFFやらDQの発売日翌日に遅刻した予備校生の言い訳みたいなのは。
327:デフォルトの名無しさん
07/03/13 14:25:23
それより昼に仏跳麺を食った後に目薬を買おうとミドリ薬品に寄ったら会社の山下
さん（結構かわいい）がレジで支払いしてるトコだった。そのレジ台に置いてあったの
がイチジク浣腸の１０個入りパッケージ。もう裕子ちゃんがお尻にイチジク浣腸を入
れてるのを想像して今も勃起しっぱなし。このことは会社の同僚にはだまってる。
噂を流したら俺だってわかるし山下さんもかわいそうだから。
328:デフォルトの名無しさん
07/03/20 01:14:45
動画エンコってマルチスレッド化するより単純にコアの数だけ時間か容量で等分して
それぞれエンコさせたファイルをつなぎ合わせた方が速そうな気がするけど、結局は>>106,115,209なの？
329:デフォルトの名無しさん
07/03/20 22:13:18
linuxでやれ。
330:デフォルトの名無しさん
07/03/21 15:28:42
やってみる価値は非常にありそうだな。
331:デフォルトの名無しさん
07/03/21 16:43:18
つなぎ目ってどうするんだろう
mpegでいうIフレームにすればいいだけ？
332:デフォルトの名無しさん
07/03/21 20:02:48
>>331
たぶんそうなんじゃない。
動画は前の画像の圧縮して解凍したものを使うから
ある程度の時間の動画をひとつのスレッドにしたほうが
効果ある上に作るのがとても楽だね。
333:デフォルトの名無しさん
07/03/21 21:17:47
キャッシュ効率が下がるんじゃない？
334:デフォルトの名無しさん
07/03/21 21:47:44
下がるだろうね。
キャッシュ重視で1枚の画像を複数のスレッドでMPEG圧縮する。
手間かける余裕があるかどうか。
CPUのマルチコア化を一般ユーザが使うようになるころは
メモリとかHDDの性能はどうなるのかしら。
335:デフォルトの名無しさん
07/03/21 22:43:12
エンコードに必要なワーキングセットをＮとすると
総キャッシュ量/Nより多いスレッド数でやると効率下がるだけやね
・・・そこまでやるか？
336:デフォルトの名無しさん
07/03/22 03:49:20
ここだと一般論を装った妄想でお茶を濁されがちだから
Core2限定の専用スレ立てていい？
337:デフォルトの名無しさん
07/03/22 11:25:18
ダンゴ様の許可があればいい
338:デフォルトの名無しさん
07/03/22 14:28:33
>>336
Xeonは除外?
339:デフォルトの名無しさん
07/03/23 02:25:42
>>336
どんな話がどう濁されているのか具体的に。
そもそも過疎ってるんだしスレを良い方向に変えていくのも一つ。
>>338
XeonもCore2ファミリじゃね?
340:デフォルトの名無しさん
07/03/23 02:55:13
初期のXeonもCore2だっけ?
341:デフォルトの名無しさん
07/03/23 03:15:39
ダンゴ的にはどうよ？
342:デフォルトの名無しさん
07/03/29 00:56:14
結局は高クロックのシングルコアが速い？
343:デフォルトの名無しさん
07/03/29 04:29:47
それができないからthe free lunch is overなのでは？
344:デフォルトの名無しさん
07/03/29 20:44:06
Core2は使うレジスタ数を減らせば速いとかどっかで見たんですが
どういうことでしょうか
Pen3やNetBurst系とは逆？
345:デフォルトの名無しさん
07/03/30 00:00:33
この質問はダンゴじゃないとマトモに返答できないと見た
346:・∀・）っ-○◎●
07/03/30 01:52:36
.
347:デフォルトの名無しさん
07/03/30 03:33:19
32bitモード、つまり
増えたレジスタを活かさないモードなら速い、ということなら
皆知ってるけどね。
348:デフォルトの名無しさん
07/03/30 22:22:50
人間活動 → スカラ
自然現象 → ベクトル
中途半端 → 今のCMP全般
349:デフォルトの名無しさん
07/04/03 09:13:21
＿＿＿_
／⌒ ⌒＼ ﾎｼﾞﾎｼﾞ
／（ ●） （●）＼
／::::::⌒（__人__）⌒::::: ＼ ＜で？
| ｍj |ー'´ |
＼ 〈＿_ﾉ ／
ノ ﾉ
350:デフォルトの名無しさん
07/04/03 19:26:14
おちんぽ
351:デフォルトの名無しさん
07/04/13 21:20:44
結局、下手に最適化せずに、単純なバイナリで、プロセッサに条件予測させた方が速いってことか。
352:デフォルトの名無しさん
07/04/15 03:08:29
既出かもしれんけど
URLﾘﾝｸ(cag.csail.mit.edu)
353:デフォルトの名無しさん
07/05/06 00:35:15
JCSPの話はここでいいのか？
354:デフォルトの名無しさん
07/05/06 02:41:23
良いんじゃない。
Java 固有の質問だったら Java のスレでやった方が良いかもしれないけどね。
355:デフォルトの名無しさん
07/06/03 02:01:31
保守
356:デフォルトの名無しさん
07/06/03 15:31:56
逐次処理を並列処理に分割する手法で代表的なものって何？
357:デフォルトの名無しさん
07/06/03 15:33:02
OpenMP とか関数型言語で書き直すとか？
358:デフォルトの名無しさん
07/06/03 15:41:12
>>356
OpenMP、pthread、MPI 辺りですかね。
# SMP 環境でわざわざ MPI する人も少ないかもしれませんが。
ちなみに性能的には MPI > pthread > OpenMP、
お手軽さでは OpenMP > pthread > MPI の順でしょうか。
359:デフォルトの名無しさん
07/06/03 16:43:38
>>358
>ちなみに性能的には MPI > pthread > OpenMP、
ええっ!? SMP環境でMPIってpthreadより性能いいの?
360:デフォルトの名無しさん
07/06/03 17:47:44
OpenMP、pthread、MPI ってどこにあるの？
361:デフォルトの名無しさん
07/06/03 18:15:19
一番星を右に進んだ所、虹の彼方に
362:デフォルトの名無しさん
07/06/04 19:05:59
ジョブを並列に分割する際に、何に注目して並列化すればよいのでしょう？
データですか？タスクですか？
363:デフォルトの名無しさん
07/06/04 19:20:07
適材適所。
364:デフォルトの名無しさん
07/06/04 19:22:08
栄枯盛衰
365:デフォルトの名無しさん
07/06/06 00:22:34
>>359
MPIは複数の計算ノード（例えばPCとか）を高速な通信回線で接続した
HPCクラスタ用ですね。
pthreadは共有メモリシステムじゃないと使えないので、CPUの数を増や
してもいくつかの理由（メモリアクセスの集中やキャッシュコヒーレンシ
維持のためのオーバーヘッド増加）のために、システム全体の性能はある
程度で飽和してします。大体 CPU 8〜16 個くらいが限界でしょうか。
クラスタシステムではCPUだけではなくメモリも分散配置しているので、
うまく仕事を複数のノードに配分するようにプログラムを作ることがで
きれば、もっとCPUを増やしてもシステム性能を向上させることができ
ます。
# でもそのソフトを作ったりデバッグするのが大変なので、MPIは暇な
# 学生が使える教育機関でしか人気が無いような気がする…。
366:デフォルトの名無しさん
07/06/06 13:37:00
>>365
MPIが性能を十分に発揮するのは「高速な通信回線で接続したHPCクラスタ」での話ですよね
>>358
># SMP 環境でわざわざ MPI する人も少ないかもしれませんが。
>
>ちなみに性能的には MPI > pthread > OpenMP、
>お手軽さでは OpenMP > pthread > MPI の順でしょうか。
「SMP 環境でわざわざ MPI」してpthreadより性能を発揮する場面ってあるんでしょうか?
あるいは下から2行目の「MPI」っつてるのは「高速な通信回線で接続したHPCクラスタ」が前提と読むべきなんですかね?
367:デフォルトの名無しさん
07/06/07 11:12:37
358じゃないけど、
>>366
>「SMP 環境でわざわざ MPI」してpthreadより性能を発揮する場面ってあるんでしょうか?
SMPだけどNUMAなアーキテクチャとかどうなんだろ。Opteronマシンみたいなの。
pthreadでNUMA考慮して書けばいいけど、間にMPIはさんどくと、誰かが最適化してくれるかもしれない。
もう最適化されてるのかな？
MPIはHPCクラスタ用っていうけど、日立やNECも自社のスパコン用にMPI提供してて、
クラスタならmpich、スパコンならベンダオリジナルのMPIってことで計算コードを使いまわせるんで、
MPIの利用率は高いと思う。10年ぐらい前スパコン使ってたころは高かった。
メモリ共有ノード内と、分散メモリになるノード間の通信の使い分けとか考えたら、
トップスピード出すにはMPIか、その手のライブラリ使うことになると思う。
368:デフォルトの名無しさん
07/06/07 23:03:08
>>367
>SMPだけどNUMAなアーキテクチャ
これは定義矛盾
Opteron は NUMA
NUMA への最適化は最近のカーネルなら大抵入ってるよ
369:デフォルトの名無しさん
07/06/07 23:13:02
>>367
もまいはこれよめ
URLﾘﾝｸ(www.amd.com)
370:デフォルトの名無しさん
07/06/15 00:05:56
これってどう？
URLﾘﾝｸ(www.rbbtoday.com)
371:デフォルトの名無しさん
07/06/15 00:10:53
機械語レベルで、並列化すんだろな
能書きは本当か知らんけど発想はありだな
372:デフォルトの名無しさん
07/06/15 00:13:22
>>370
URLﾘﾝｸ(www.nec.co.jp)
これのことか？
373:デフォルトの名無しさん
07/06/15 06:55:05
何を並列化するかによるわな。
マンデルブロ集合の計算とか、完全に並列化できるものなら、そらN台でN倍に
なるだろうけど、そんな簡単な用途は極めてまれなわけで。
宣伝の一人歩きだろう。
374:デフォルトの名無しさん
07/06/15 07:46:05
＞極めてまれ
そうでもない。
処理はシンプルでも大量に捌かないといけない場合はままある。
#尤も、そういうケースは並列化の自動化も難しいが。
375:デフォルトの名無しさん
07/06/16 01:44:51
んなこたあねえべさ。
むしろ順次処理じゃないといけない場面の方が少ないんじゃねぇかな？
376:デフォルトの名無しさん
07/06/16 02:10:48
画像処理とオンライン系のトランザクションは並列化に向いてる処理が多いって
よくいわれるよね。××ルータ、××フィルタ、××サーバと名前に付くアプリは
並列化してナンボな物が多い。
デスクトップアプリは 4 コアもあれば十分だと思うけど。
377:デフォルトの名無しさん
07/06/16 11:53:25
大規模マルチコアプロセッサの発売に向け準備を進めるインテル
URLﾘﾝｸ(japan.cnet.com)
IntelのTera-Scale Computing Research Program担当共同ディレクタ
ーJerry Bautista氏によると、現在、Intelの研究者らは、コンピュータ
メーカーやソフトウェア開発者らが、大量のコアを搭載するマルチコア
チップにより簡単に適応できるようにするため、それらのチップの複雑
な機能性を意識させないための手段を模索しているという。
異種マルチコアチップ内のすべてのコアを外骨格のようなもので覆い、
それらすべてのコアを複数の従来型x86コア、あるいは1個の大きなコア
に見立てる。Bautista氏は、「それは、いわば1つのリソース貯蔵庫のよ
うになり、ランタイムがその中から適当と思うものを使用する」と述べ、
「これはプログラミングを簡略化するためだ」と付け加えた。
1個のチップ内の多様なコア間で演算タスクを分配するハードウェアスケ
ジューラを使用することにより、特定の演算タスクをより短時間で完了
できるとBautista氏は指摘する。
プログラマーたちは、キャッシュ共有技術やハードウェアスケジューリング
技術を理解したり、これに対応するためにたくさんの労力をつぎ込む必要
はない。これらのオペレーションは大抵、チップ自体によって処理される
ため表面化しないのである。
378:デフォルトの名無しさん
07/06/16 16:38:55
>>377
素晴らしい！！
テクノロジーの進化ってとんでもねぇなｗ
379:デフォルトの名無しさん
07/06/16 22:47:24
Windows出たばかりの頃の宣伝の様だが
380:デフォルトの名無しさん
07/06/16 22:56:25
まあイソテルの「プログラミングの簡略化」の範囲はアプリ屋の話で、
コンパイラ屋ガンガレ、死ぬまでガンガレ by Intel
って漏れの耳には聞こえてるが気のせい？
381:デフォルトの名無しさん
07/06/16 23:05:49
>>380
そういうのは NetBurst や Itanic で懲りていると思いたい…
382:デフォルトの名無しさん
07/06/16 23:42:46
>380
俺にはIntel以外のコンパイラは淘汰されてしまえ
と聞こえるが
383:デフォルトの名無しさん
07/06/16 23:54:34
ARM、gcc、VC++でつかえなけりゃいみねぇー
世の中ICCが全てみたいな発想がすかん
INTELはいっつもAMDいじめて悦に浸ってる変態だし
しねってかんじだ
384:デフォルトの名無しさん
07/06/17 00:13:12
そらそうよ、Intelはパラノイアが社訓だもん
385:デフォルトの名無しさん
07/06/17 01:16:16
いよいよAMDの時代
URLﾘﾝｸ(northwood.blog60.fc2.com)
URLﾘﾝｸ(northwood.blog60.fc2.com)
URLﾘﾝｸ(northwood.blog60.fc2.com)
URLﾘﾝｸ(blog.livedoor.jp)
386:デフォルトの名無しさん
07/06/17 01:23:55
Intel社、ソフトウエアの並列化が研究開発部門の最重要課題に
URLﾘﾝｸ(www.eetimes.jp)
マルチコア・プロセッサに対する需要の高まりを受け、米Intel社はソフトウエア
の並列化を最重要課題に掲げている。その取り組みの一環として、特定用途
向けプログラミング言語や既存のプログラミング言語/アプリケーションの並列化
に関する研究に250名を投入している。「オレゴン州にある研究開発部門では、
全業務の実に約3/4をソフトウエア関連が占める」
インテルが開発ツールの新版を発売、ソフトウエアの並列化を支援
URLﾘﾝｸ(www.eetimes.jp)
コンパイラは、ベクトル化が可能な場合、SSE命令セットを利用したコードを
生成する。また、C++のテンプレート・ライブラリとして実装されているTBBを
利用すると、ソフトウエア開発者が明示的にコードを記述しなくても、マルチ
スレッド化できる。OpenMPライブラリを利用しており、実行時に利用可能な
コア数分だけスレッドを生成する。
387:デフォルトの名無しさん
07/06/17 15:02:51
AMDは甘ちゃん
IBMとIntelはプロフェッショナル
388:デフォルトの名無しさん
07/06/18 01:10:40
次世代スパコンはスカラーとベクトルの複合型に，日立/NEC/富士通の「3社連合」で開発へ
URLﾘﾝｸ(techon.nikkeibp.co.jp)
アーキテクチャの概要は，スカラー型プロセサからなる演算システムにアクセ
ラレータを付加し，さらにベクトル型プロセサからなる演算システムを組み合わ
せる，というもの。スカラー部とベクトル部は，共有ファイル・システムを介して
データをやり取りする。これによって様々な大規模計算シミュレーションが計算
のタイプに合わせた演算環境を選べるようになる。
ハードウエアだけでなく，ソフトウエアも同時に開発する。「制御フロントエンド」
のジョブ管理を通して，ユーザーはこれら二つのシステムの違いを意識せずに
最適な演算環境を選べるようにするという。
389:デフォルトの名無しさん
07/06/18 06:50:59
>>384
コンピュータ様って事ですね？市民。
390:デフォルトの名無しさん
07/06/18 23:42:06
もうすぐメニーコアがでてくるらしい。
システム設計とかどうすりゃいいんだか・・・
URLﾘﾝｸ(pc.watch.impress.co.jp)
391:デフォルトの名無しさん
07/06/18 23:46:07
いつも通り、頭のいい人が仕組みを考えて、俺らがそれに乗っかって儲ける
で良いんじゃないかな。頭のいい人の代わりを務めようとすると大変だけど。
392:デフォルトの名無しさん
07/06/18 23:51:36
シーケンス図廃止からやってみようかな？
で、その代わりに何を使えばいい？？
393:デフォルトの名無しさん
07/06/19 18:18:04
並列システム用のモデリングviewをUMLに策定してくれんかな。
394:・∀・）っ-○◎●
07/06/20 00:23:28
あのさー
マルチコアに限らずソフトの最適化なんて、現場レベルでボトルネック分析し
どこを重点的に並列化するか設計フェイズにフィードバックしながらやっていくもんで
日本伝統のウォーターフォールモデルじゃ、いくらお絵かきツールが便利になっても
全然役に立たんよ。
むしろUMLの本質は抽象化なんでそもそもマルチコアを意識する必要ねぇ。
逆に具体化しちゃうと、コア数の増減やパフォーマンスの見積もり違いで破綻する希ガス。
マルチスレッドは一般的にはObserverパターン、と本で得た知識をそのまま晒してみる。
URLﾘﾝｸ(www.hyuki.com)
それにしても結城先生お茶目だな。
395:デフォルトの名無しさん
07/06/20 00:28:27
さてと、、、
396:デフォルトの名無しさん
07/06/20 16:51:08
Cellスレでボコボコにされて
泣く泣くこちらのスレに逃げてきた団子が
ご迷惑をおかけしております。
397:・∀・）っ-○◎●
07/06/20 22:12:33
ゲハ厨自演乙
398:デフォルトの名無しさん
07/06/21 00:00:47
>>396
バカかお前ｗｗｗ
何も知らないんだなｗｗｗｗｗ
ム板で厨認定された糞団子が帰る場所は
学歴とゲハだよｗｗｗｗｗｗｗｗ
399:デフォルトの名無しさん
07/06/21 15:37:25
該当するスレが見付からず、
かといってどこにかけばいいかわからないのでここで質問をします
(どこか適当なスレがあれば誘導していただければ幸いです)
今、FreeBSD 6.2のPCからPVMを起動して
Fedora 7(192.168.1.3)とVine Linux 4.2(192.168.1.4)のPCをクラスタに登録したいのですが
登録の成功をつげているのにもかかわらず
マシンには登録されていないような状況になっています
/tmp/pvml.????(????：グループID)を確認したら以下のようなメッセージが
でてきます
------------------------------
[t80040000] 06/21 15:11:35 host1 (192.168.1.2:60822) FREEBSD 3.4.5
[t80040000] 06/21 15:11:35 ready Thu Jun 21 15:11:35 2007
[t80040000] 06/21 15:14:50 netoutput() timed out sending to ryle after 14, 190.000000
[t80040000] 06/21 15:14:50 hd_dump() ref 1 t 0x80000 n "ryle" a "" ar "LINUX" dsig 0x408841
[t80040000] 06/21 15:14:50 lo "" so "" dx "" ep "" bx "" wd "" sp 1000
[t80040000] 06/21 15:14:50 sa 192.168.0.3:32790 mtu 4080 f 0x0 e 0 txq 1
[t80040000] 06/21 15:14:50 tx 2 rx 1 rtt 1.000000 id ""
[t80040000] 06/21 15:16:40 netinput() bogus pkt from 192.168.1.3:32790
------------------------------
PVMの方で勝手にタイムアウトをしているのですが
このような場合はどのようにすれば回避できるのでしょうか？
400:デフォルトの名無しさん
07/06/21 22:38:31
簡単なファイルコンバート処理(ファイル読み込み→変換→ファイル出力)を並列化したいんだけど、定番のパターンとか定石ってある？
自分で調べた感じだとProducer-Consumerパターンが使えそうなんだけど・・・。
401:デフォルトの名無しさん
07/06/23 18:29:29
UNIXのパイプ
402:デフォルトの名無しさん
07/06/24 23:14:58
フィックスターズが出している
URLﾘﾝｸ(www.shuwasystem.co.jp)
は、役に立つのだろうか？
立ち読みした限りでは内容がちと薄い気がするのだが。
403:デフォルトの名無しさん
07/06/26 16:17:27
>>402
それ持ってるけど、動くプログラムが書かれているだけで幸せ。
とりあえずコードを何回も書いて覚えている途中。
変な癖が付きそーだったら「違うよ」って教えてくれるとウレシイ。
404:デフォルトの名無しさん
07/06/26 20:43:30
そんなレベルの奴が並列化なんかに手を出すのが間違い
405:デフォルトの名無しさん
07/06/26 21:33:51
並列かなんてたいして技術いる事じゃないだろ
406:デフォルトの名無しさん
07/06/26 23:43:46
そういうやつが平気でぼけぼけかますのが並列化
407:デフォルトの名無しさん
07/06/26 23:46:28
科学計算レベルでの並列化と業務ソフトの並列化は同じレベルでは
語れないと思うんだが。そんな意味で入門には>>402はちょうどいい。
javaERの俺にはﾀﾞｸﾞﾘｰ先生の本のほうが面白かったけど。
408:デフォルトの名無しさん
07/06/26 23:48:17
>>406
一緒にするなよ
409:デフォルトの名無しさん
07/06/27 08:23:06
Amazonでの評価は微妙だね。
URLﾘﾝｸ(www.amazon.co.jp)
410:デフォルトの名無しさん
07/06/27 18:12:05
俺は釣られないぞ
411:デフォルトの名無しさん
07/06/29 01:44:41
なんでOpenMPばっか期待されてんの？
どこにもOpenMPなんて書いてないように見えるが（本のタイトルとかに）
412:デフォルトの名無しさん
07/06/29 01:46:42
デザインパターンの本。
↓
Javaについてはほとんどのってないので期待はずれ。
↓
デザインパターンの本、評価は微妙。
だれもJavaって言ってないじゃん…
413:デフォルトの名無しさん
07/06/29 13:17:14
たしかに目次にも一言もOpenMPの文字はないね。。。
よく分からん書評だ。
俺は↓の本で勉強したけど分かりやすかった。くどいくらいだけど。
Win32マルチスレッドプログラミング
URLﾘﾝｸ(www.amazon.co.jp)
414:デフォルトの名無しさん
07/07/06 09:47:57
URLﾘﾝｸ(www.ebjapan.com)
これってハードレベルで並列を実現したってこと？
415:デフォルトの名無しさん
07/07/06 12:21:00
>>414
説明読んでいたら、家政婦が私語を始めたり、殺人事件を目撃したりしてしまう展開が脳内を過ぎった。
416:デフォルトの名無しさん
07/07/07 21:55:50
業務レベルでの並列と、コードレベルでの並列って差があると思うのだが
対処方法ってどうなってるでしょうね？
417:デフォルトの名無しさん
07/07/07 22:04:37
>>415
FPGAのparallel random access machine/model
じゃねーのそれって？
しかし今回はそれを1個だけしか作れていないはず。
64個最大実装時（現在開発中）が現行CPUの100倍程度って事だな
まぁ、IntelとかにX86を32個とか載せた板作ってもらった方が
書きやすいと思われる。価格も現実的だし。
418:デフォルトの名無しさん
07/07/07 22:18:17
URLﾘﾝｸ(seisei.s8.xrea.com)
これはどうなんだろうね？
419:デフォルトの名無しさん
07/07/07 22:39:58
>>418
うさんくさすぎねーかw
これが全部実現できるならIPAとかに公募して金もらうはず。
なんか穴があるはずだ。実用上の
420:デフォルトの名無しさん
07/07/07 23:05:23
>>418
すげぇ、胡散臭すぎて読む気にもならないよ。
421:デフォルトの名無しさん
07/07/07 23:29:44
読んでみたが、xorの計算をマルチスレッドで演算するソフトなわけね。
速度が速くなるとは書いてないようだな。
で？
422:デフォルトの名無しさん
07/07/09 01:01:13
XORをまるちすれっど？
で？
423:デフォルトの名無しさん
07/07/10 10:41:52
オーバーヘッドが少ないとか、実行時効率が良くなるとかじゃないみたいね。
分かりやすい管理方式の提案？
で？
424:デフォルトの名無しさん
07/07/10 11:41:21
順序立てて処理する必要が無い部分はマルチスレッドで並列処理すれば蝶早く計算できる！
俺天才！！！
って事？ｗ
URL削るともっと胡散臭いｗ
425:デフォルトの名無しさん
07/07/10 15:18:46
えーと自家製単純インタプリタ(command)が
並列にできるところを並列化、
という感じ？
じゃなくてこれは単なる dish の簡単な使用例か。
URLﾘﾝｸ(www2.chem.nagoya-u.ac.jp)
426:デフォルトの名無しさん
07/07/11 22:20:15
>>424
やばい、ドキュメントDLで金とるよ的なページもある。
427:デフォルトの名無しさん
07/07/11 23:45:26
419です。
スマン、どうやらスレ汚しをしてしまったようだ。
削除依頼してくるわ。
428:デフォルトの名無しさん
07/07/12 00:01:42
ごめん、↑は418の間違いね
429:デフォルトの名無しさん
07/07/12 02:56:59
そりゃ潔癖すぎる
気楽にやろうぜ
430:デフォルトの名無しさん
07/07/17 07:17:14
クロック数が違うCPUでマルチコア作ってほしい。
200MGHくらいのCPUが30個くらいついていて、2G強のCPUが一個くらいのやつ。
タスクで重いやつを2Gのやつに振るとかの処理はOSなりPG任せにする仕組みで。
無理か？
431:デフォルトの名無しさん
07/07/17 09:33:39
200MGHってのがどんなCPUか知りませんが、やってできないことではありません。
まぁ殆ど、意味はないと思いますが。
432:デフォルトの名無しさん
07/07/17 11:49:26
メガドラか
433:デフォルトの名無しさん
07/07/17 12:32:41
200メガギガヘンリー
434:デフォルトの名無しさん
07/07/17 12:38:57
200万ギザエッチ
435:デフォルトの名無しさん
07/07/17 12:57:02
200マゾガチハーレム
436:デフォルトの名無しさん
07/07/17 21:41:58
ダンゴさんのレスが望まれるところだ
437:デフォルトの名無しさん
07/07/18 01:21:03
悪趣味だな。
438:・∀・）っ-○◎●
07/07/18 02:51:49
だーんごー
だーんごー
たーっぷりー
だーんごー
439:デフォルトの名無しさん
07/07/18 11:04:21
>>438
おいこら、「つぶつぶだんご」ってフレーズが頭ん中でリピートしちまったじゃないか。
440:デフォルトの名無しさん
07/07/18 21:12:27
>438
それ、たらこだろ？
441:デフォルトの名無しさん
07/07/18 23:45:04
キャッシュヒット率を多少改善するくらいしかやれることなんてないだろ
442:デフォルトの名無しさん
07/07/18 23:50:16
イチローの出番だわな
443:デフォルトの名無しさん
07/07/19 10:24:49
>>430
ヘテロなマルチコアならcellがあるじゃまいか
444:デフォルトの名無しさん
07/07/19 11:45:36
そうじゃなくてね、クロック数の低いコアを十数個のせて低コストのプロセス
なりスレッドを割り当てして、OSなどの重い処理専用のコアというふうにわけ
れば効率よくマルチプロセス・スレッドができると思ったのよ。
>200MGH
200MHと間違えたよorz
445:デフォルトの名無しさん
07/07/19 16:09:31
＞クロック数の低いコアを十数個のせて低コストのプロセスなりスレッドを割り当てして
重い処理をするコアが数パーセントの稼働率でその処理やればいいんじゃない？
あまった時間はクロックダウンして各種電源OFFしてればいいし。
ってのはともかくとして、キーボードやスイッチ、外部デバイスの監視みたいな
低速簡単タスクはPICとか使ってやってるシステムもあるよね。
446:デフォルトの名無しさん
07/07/19 16:19:17
どうやって低コストかどうかを判断するんだ。
アプリ自体にプロセス毎の振り分けフラッグでも付いてないと適切に割り当てられんし、
低コストならメインCPUでやっちゃってもすぐ終わるから問題ないとも言える。
その考え方ならCPUコア分割よりIOコストをうまく割り振ってどれだけCPUをビジーに保てるかを
考えたほうが建設的だと思う。
447:デフォルトの名無しさん
07/07/19 21:07:21
分散すれば仕事が早くなるってアホな幻想いだいてるから
間違った方向にいくんだよなぁ。
人も機械もどれだけパンクギリギリまで仕事詰め込めるかが命なのに
448:デフォルトの名無しさん
07/07/19 22:52:24
>分散すれば仕事が早くなるってアホな幻想
お前がアホなんだろｗ
449:デフォルトの名無しさん
07/07/19 23:32:58
無理なものは無理
450:デフォルトの名無しさん
07/07/20 00:00:15
つまり馬鹿に仕事を割り振る方法を考える時間があったら
自分でやった方が速いってことだな。
451:デフォルトの名無しさん
07/07/20 00:42:36
工場の単純労働者は1000人必要かもしれない
だからといって社長（＋役員）は20人もいらない
452:デフォルトの名無しさん
07/07/20 00:50:41
でもXeon20個搭載可能なマシンあったら
夢がひろがりんぐだろw
453:デフォルトの名無しさん
07/07/20 00:58:53
>>452
それなんていう暖房機具？
454:デフォルトの名無しさん
07/07/20 01:32:05
1UラックマウントのXeon*2搭載可能なサーバがあるから、10Uラックでいけるな。
暖房器具っつーか、騒音源だな。
455:デフォルトの名無しさん
07/07/20 02:00:49
今なら１U3台で済むよ
QuadXeon 6個＋ﾏﾏﾝ3枚でｵｹ
456:デフォルトの名無しさん
07/07/20 06:53:20
Xeon20個っていってるのに6個って、何考えているんだ?
まさか、Xeon20個ってコア数だとおもっているのか?
おめでたいな。
457:デフォルトの名無しさん
07/07/20 09:27:02
頭が4つもついてる役員は怖いです。
458:デフォルトの名無しさん
07/07/20 11:07:36
バスが飽和しそうです。
459:デフォルトの名無しさん
07/07/20 23:18:00
>>454-456
お前らブレードサーバも知らんのか？
6U で Xeon 20個 コア 80個ぐらいは積めるだろ。
460:デフォルトの名無しさん
07/07/24 21:52:02
URLﾘﾝｸ(japan.cnet.com)
461:デフォルトの名無しさん
07/07/25 00:49:04
GPL？
462:デフォルトの名無しさん
07/07/25 00:55:38
記事読んだ感じだと、例外付き GPL なんじゃないの
463:デフォルトの名無しさん
07/07/26 00:26:11
LGPLだなたしか。
でも実際これら使っても効果出る範囲狭いみたいだぞ。
464:デフォルトの名無しさん
07/08/04 20:15:15
タスク境界を自動で検出するTOOLないかね？
465:デフォルトの名無しさん
07/08/16 15:32:15
foobarなどで複数のエンコーダを使って処理速度を上げてるってやつがあるけど
よっぽどうまく設計しないとハードディスクへのアクセスがボトルネックとなるじゃね。
466:デフォルトの名無しさん
07/08/21 09:25:35
URLﾘﾝｸ(www.itmedia.co.jp)
467:デフォルトの名無しさん
07/08/21 16:40:31
>>465
どういう計算だよｗ
468:デフォルトの名無しさん
07/08/21 22:27:55
URLﾘﾝｸ(pc.watch.impress.co.jp)
469:デフォルトの名無しさん
07/08/22 13:13:48
URLﾘﾝｸ(www.atmarkit.co.jp)
470:デフォルトの名無しさん
07/08/23 22:07:23
URLﾘﾝｸ(pc.watch.impress.co.jp)
471:デフォルトの名無しさん
07/08/31 20:12:44
Wikiﾍﾟﾃﾞｨｱより
>また、Windows Vista Home Basicおよび同Home Premiumではマルチプロセッサには対応しておらず
マジか
472:デフォルトの名無しさん
07/08/31 20:16:45
>>471
そこでいうマルチプロセッサは、マルチソケットのことでマルチコアでは
ないことは理解してる？
473:デフォルトの名無しさん
07/08/31 20:26:13
一応理解している。
シングルコアをくっつけて作るデュアル環境と、ダイに複数コアをのっける
ものの違いだと認識している。
多分
474:デフォルトの名無しさん
07/08/31 20:40:22
XP HOMEもそうだったでしょ。
物理CPUに対応してるのは１個まで。
物理CPU１個ならコアが４個あっても大丈夫（のはず）
物理CPU２個はXP PROFESSIONALから。４個以上は知らない。
475:デフォルトの名無しさん
07/08/31 22:48:30
それは違うぞ。
476:デフォルトの名無しさん
07/08/31 23:02:14
じゃあどうなの
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5387日前に更新/215 KB
担当:undef