ItaniumをUNIXで使うスレ

[1 名無しさん＠お腹いっぱい。 2008/07/14(月) 19:44:39]

実際に使ってみた人、どうよ?

前スレ
ItaniumでUNIX!
http://pc11.2ch.net/test/read.cgi/unix/1140329582/

[256 名無しさん＠お腹いっぱい。 2008/12/02(火) 12:19:54]

>>254
FreeBSD/ia64だとXが使えないのが苦しい所だな。

[257 名無しさん＠お腹いっぱい。 2008/12/02(火) 12:28:22]

>>255
まさに使うだけだったからRHEL3で間に合ってたのだけど、
作業環境としては要らなくなったので、気分転換しようかと。

実験環境としてはdebianだと保守的すぎてつまらないし、
Fedora9で良さそうね。

[258 名無しさん＠お腹いっぱい。 2008/12/02(火) 13:18:51]

>>253
> クロックを低く抑えられ、ビット幅も小さくできるので、実装コストが安いことが利点だね。

はぁ〜。どーしよーもねーな。
まあ、その程度じゃなきゃ共有バスで SMP性能が出るなんて思わんわな。
Wikipedia の「バス（コンピューター）のとこでも読んでみれ。話にならん。

| ...スター型トポロジとなるクロスバースイッチ（クロスバーバス）が
| ワークステーション等に採用されている。これは複数のCPU・メモリ間で
| 多対多の転送（通信）を同時に行えるようにしたもので、...

多対多で同時ね。は〜、疲れるわ。

[259 名無しさん＠お腹いっぱい。 2008/12/02(火) 16:09:09]

>>258
こっちのほうが疲れるぞ。
思いっきり単純化して、スヌープとか調停とか端折りまくって説明するとだな。

■データ転送がクロスバーの場合、↓のようにデータ転送は多対多で同時に行えるので、
64バイトの転送を16バイトずつ4クロックに分けてもOK

ステップ1) ノードAのCPUがノードCのメモリの読み取りを要求
ステップ2) ノードBのCPUがノードDのメモリの読み取りを要求
ステップ3) ノードCのCPUがノードAのメモリの読み取りを要求
ステップ4) ノードDのCPUがノードBのメモリの読み取りを要求
略
ステップ5) ノードCのメモリから、ノードAのCPUに向けてデータ転送開始
ステップ6) ノードDのメモリから、ノードBのCPUに向けてデータ転送開始
ステップ7) ノードAのメモリから、ノードCのCPUに向けてデータ転送開始
ステップ8) ノードBのメモリから、ノードDのCPUに向けてデータ転送開始
略
ステップ9) ノードCのメモリから、ノードAのCPUに向けてデータ転送終了
ステップ10) ノードDのメモリから、ノードBのCPUに向けてデータ転送終了
ステップ11) ノードAのメモリから、ノードCのCPUに向けてデータ転送終了
ステップ12) ノードBのメモリから、ノードDのCPUに向けてデータ転送終了

[260 名無しさん＠お腹いっぱい。 2008/12/02(火) 16:10:44]

■データ転送がバスの場合、↓のようにデータ転送は同一のバスを時分割で行うので、
64バイトの転送を64バイトぜんぶまとめて1クロックで行わないといけない

ステップ1) ノードAのCPUがノードCのメモリの読み取りを要求
ステップ2) ノードBのCPUがノードDのメモリの読み取りを要求
ステップ3) ノードCのCPUがノードAのメモリの読み取りを要求
ステップ4) ノードDのCPUがノードBのメモリの読み取りを要求
略
ステップ5) ノードCのメモリから、ノードAのCPUに向けてデータ転送
ステップ6) ノードDのメモリから、ノードBのCPUに向けてデータ転送
ステップ7) ノードAのメモリから、ノードCのCPUに向けてデータ転送
ステップ8) ノードBのメモリから、ノードDのCPUに向けてデータ転送

逆に言うと、データ転送が1クロックで終わるなら、クロスバーにする意味はなくてバスでよい。

[261 名無しさん＠お腹いっぱい。 2008/12/02(火) 16:35:39]

>>260
> 逆に言うと、データ転送が1クロックで終わるなら、クロスバーにする意味はなくてバスでよい。

あのなぁ........................ そういう前提がまちがってるし。
今 6coreが 4ソケットって話してるんだが、コアが 24という前提でやってくれるか?
1:4クロックでノード数 4て、日頃からそいういうインチキ語って暮らしてるの?

逆に言えば、上の例だと 5CPU以上ダメじゃん。実際オーバーヘッド入れたら
共有バスだと 4CPUもキツイ、というのにモロ符合するけどなw

オレもヒマだなw

[262 名無しさん＠お腹いっぱい。 2008/12/02(火) 16:47:29]

>>261
> 逆に言えば、上の例だと 5CPU以上ダメじゃん。

4ノードの時点で16CPUなんだが・・・

まぁいいや5ノードで書いてみる。

■データ転送がクロスバーの場合、↓のようにデータ転送は多対多で同時に行えるので、
64バイトの転送を16バイトずつ4クロックに分けてもOK

ステップ1) ノードAのCPUがノードCのメモリの読み取りを要求
ステップ2) ノードBのCPUがノードDのメモリの読み取りを要求
ステップ3) ノードCのCPUがノードEのメモリの読み取りを要求
ステップ4) ノードDのCPUがノードAのメモリの読み取りを要求
ステップ5) ノードEのCPUがノードBのメモリの読み取りを要求
略
ステップ6) ノードCのメモリから、ノードAのCPUに向けてデータ転送開始
ステップ7) ノードDのメモリから、ノードBのCPUに向けてデータ転送開始
ステップ8) ノードEのメモリから、ノードCのCPUに向けてデータ転送開始
ステップ9) ノードAのメモリから、ノードDのCPUに向けてデータ転送開始
ステップ10) ノードBのメモリから、ノードEのCPUに向けてデータ転送開始
略
ステップ11) ノードCのメモリから、ノードAのCPUに向けてデータ転送終了
ステップ12) ノードDのメモリから、ノードBのCPUに向けてデータ転送終了
ステップ13) ノードEのメモリから、ノードCのCPUに向けてデータ転送終了
ステップ14) ノードAのメモリから、ノードDのCPUに向けてデータ転送終了
ステップ15) ノードBのメモリから、ノードEのCPUに向けてデータ転送終了

[263 名無しさん＠お腹いっぱい。 2008/12/02(火) 16:48:34]

■データ転送がバスの場合、↓のようにデータ転送は同一のバスを時分割で行うので、
64バイトの転送を64バイトぜんぶまとめて1クロックで行わないといけない

ステップ1) ノードAのCPUがノードCのメモリの読み取りを要求
ステップ2) ノードBのCPUがノードDのメモリの読み取りを要求
ステップ3) ノードCのCPUがノードEのメモリの読み取りを要求
ステップ4) ノードDのCPUがノードAのメモリの読み取りを要求
ステップ5) ノードEのCPUがノードBのメモリの読み取りを要求
略
ステップ6) ノードCのメモリから、ノードAのCPUに向けてデータ転送
ステップ7) ノードDのメモリから、ノードBのCPUに向けてデータ転送
ステップ8) ノードEのメモリから、ノードCのCPUに向けてデータ転送
ステップ9) ノードAのメモリから、ノードDのCPUに向けてデータ転送
ステップ10) ノードBのメモリから、ノードEのCPUに向けてデータ転送

ほらね、データバスの帯域幅は4ノードと5ノードで同じだよ?

[264 名無しさん＠お腹いっぱい。 2008/12/02(火) 17:25:26]

>> 逆に言うと、データ転送が1クロックで終わるなら、クロスバーにする意味はなくてバスでよい。
> あのなぁ........................ そういう前提がまちがってるし。

クロックって言うからいけない
アドレスの1サイクルと同じ時間で終わるならって言えばいいのよ

[265 名無しさん＠お腹いっぱい。 2008/12/02(火) 19:18:29]

>>258
転送は同時にできるが、その転送の要求は同時に出せない。

[266 名無しさん＠お腹いっぱい。 2008/12/02(火) 20:01:36]

バスで 64バイトが 1クロックって、どういうことよ? 信号線 512本あるの?

[267 名無しさん＠お腹いっぱい。 2008/12/02(火) 20:17:44]

信号線が512本もあったら実装が大変だし、
かといってクロックを上げるのも大変だから、
そこで、
クロスバーですよ。

[268 名無しさん＠お腹いっぱい。 2008/12/02(火) 20:30:30]

LSI内なら512本もOK

Xeon用のチップセットは、データ部分8.5GB/secのFSBを4本と、
送受信あわせて8GB/secのFB-DIMMを4チャネル(2チャネルずつ束ねて使われることに注意)、
合計66GB/secを、
クロスバーかバスか知らないが、とにかく、コンカレント動作を妨げないように接続している。

[269 名無しさん＠お腹いっぱい。 2008/12/02(火) 22:37:56]

そろそろクロスバー盲信者にトドメ、さしとくかな。

Sun Fire 3800 2〜8プロセッサ 実効帯域幅9.6GB/sec
Sun Fire 4800 2〜12プロセッサ 実効帯域幅9.6GB/sec
Sun Fire 6800 2〜24プロセッサ 実効帯域幅9.6GB/sec
アドレスが実質的にバスなので、プロセッサが増えても9.6GB/secのまま。

[270 名無しさん＠お腹いっぱい。 2008/12/02(火) 23:16:55]

16CPU超のシステムならアプリインストールしてベンチで評価するでしょ。
そりゃこの辺の知識があれば評価対象は絞り込みやすくていいけどさ、
いい加減お互いにけんか腰やめてくんないかな

[271 名無しさん＠お腹いっぱい。 2008/12/02(火) 23:18:22]

Itanium機にRHEL3って人はhp-uxはもっとらんの？
保守入ってなきゃ新バージョンはもらえないのかな

[272 251 2008/12/02(火) 23:57:25]

>>271
hp-uxは持ってないし、ドライバサポートに難があって、
確かVGAとSCSIボードを交換する必要があった。
シリアルコンソール＆ATA接続にすりゃ動く様だが、
それじゃあWSとは言えんわなｗ
ちなみにWindowsでもそのままの構成で動く。

[273 名無しさん＠お腹いっぱい。 2008/12/03(水) 00:16:38]

> アドレスが実質的にバスなので

どこの田舎の言葉ですか?

[274 名無しさん＠お腹いっぱい。 2008/12/03(水) 01:19:53]

続きは検証センターででもやればいいのに。

[275 名無しさん＠お腹いっぱい。 2008/12/03(水) 09:37:01]

>>270
え? バスバス言ってんのは、なんか反論でもした気になってるのかよ? 笑止
小手先の付け焼き刃の延命処置をさもまっとうな対策みたいに語るのは
よくあることだけどな。

[276 名無しさん＠お腹いっぱい。 2008/12/03(水) 09:41:18]

「バスを多段にして間にキャッシュ噛ますとあら不思議、クロスバーに対抗できます。」
まとめるとこういうことだな。
「なぜなら、クロスバーはアドレス指定がバスだからです。」
クロスバー導入したエンジニア達はそれに気付かなかったわけだw

[277 名無しさん＠お腹いっぱい。 2008/12/03(水) 11:50:30]

Sun Fire 6800、アドレスが実質的にバスで飽和しまくり。
↓
「バスを多段にして間にキャッシュ噛ます」
アドレスのバスを細かく分割して、スヌープフィルタを介して相互接続することで、ボトルネック解消
↓
Sun Fire 15K、従来の10倍以上の高速化を実現!


Xeon、共有バスなので飽和しまくり。
↓
バスを分割して、スヌープフィルタを介して接続することで、ボトルネック改善


ね、一緒でしょ。

>>273
真実には逆らえず、レッテル貼りによる封じ込めに作戦変更ですか?

[278 名無しさん＠お腹いっぱい。 2008/12/03(水) 11:54:51]

ttp://www.atmarkit.co.jp/news/200110/05/sun.html
> 通常のバス・アーキテクチャでは全ての信号が1本のバスを通るため、
> CPUなどを増やして処理性能を上げようとしてもバス性能が性能向上のボトルネックとなった。
> バスを流れる「データ」「コントロール」「アドレス」の3種類の信号のうち、
> データだけがクロスバー・テクノロジによって高速化されていた。

アドレスはバスでした。

もっと詳しいことは↓でも読んでくれ。
ttp://jp.sun.com/products/wp/server/WPcat4.pdf

[279 名無しさん＠お腹いっぱい。 2008/12/03(水) 12:03:16]

ちなみに日本語訳は誤訳とかアヤシイ部分があるので、原文に当ったほうがいいかも。

原文はこちら
ttp://www.sc2001.org/papers/pap.pap150.pdf

[280 名無しさん＠お腹いっぱい。 2008/12/03(水) 12:06:31]

>>278
> アドレスはバスでした。

お前の日本語をどうにかしろと

[281 名無しさん＠お腹いっぱい。 2008/12/03(水) 12:11:16]

ていうか、すでに>>220のURLに書いてあることなんだよな。
自分で持ち出しといて、内容を読んでなかったのかな。

[282 名無しさん＠お腹いっぱい。 2008/12/03(水) 12:11:28]

...Sun Fireのクロスバーが性能改善した事実がすなわち今の Xeon MP機の
性能がいいことを証明したことになる、のかよ? 無理あり過ぎだろw
実際そうなら 8コア超の Xeon MP機の評価記事がどんどん出てくるだろうし、
飛ぶように売れるだろうからそれでわかるんだろな。
じゃあ、QPIなんてやる必要はなかったわけだw
..どのみち Itaniumは-終了-なんだな。

[283 名無しさん＠お腹いっぱい。 2008/12/03(水) 12:12:05]

>>280
アドレスは実質的にバス接続

これ、理解できないの?

[284 名無しさん＠お腹いっぱい。 2008/12/03(水) 12:12:28]

>>281
あんた相手してるの元の人間と違うぞw

[285 名無しさん＠お腹いっぱい。 2008/12/03(水) 12:14:41]

>>282
往生際が悪いぞ。

一部分でもバスだからダメというお前さんの主張を否定しただけだ。

[286 名無しさん＠お腹いっぱい。 2008/12/03(水) 13:11:23]

はあ? 往生なんかしませんが。ひょっとして追い詰めたとでも思ってるのか?!
クロスバーにすぐついてこれなかった RISCベンダーが打った対策の
焼き直しじゃないか。もっともらしく持って回ってあるが。
そいつら結局全部クロスバー行ってるし。
で、QPIはどうなんだよ? それ以上に素晴らしいバラ色の新技術か?w

[287 名無しさん＠お腹いっぱい。 2008/12/03(水) 13:16:23]

>>285
> 一部分でもバスだからダメというお前さんの主張を否定しただけだ。

ところで、バスを分割して切り替え（スイッチング）して使うのは、
それはクロスバースイッチとは明確に違うのか? 信号線も減るんだろ?
粒度の違いで区別する?

[288 名無しさん＠お腹いっぱい。 2008/12/03(水) 13:45:00]

>>283
アドレスリクエストがシェアードバスに流れると言いたいのか？
クロスバースイッチだって「バス」だぜ？

[289 名無しさん＠お腹いっぱい。 2008/12/03(水) 13:48:09]

>>286
すでにXeonはクロスバーになった、という話なんだがなぁ。

>>287
Sunは、
> バスを分割して切り替え（スイッチング）して使う
ことも、クロスバーと呼んでるようですよ。

[290 名無しさん＠お腹いっぱい。 2008/12/03(水) 13:50:41]

270だけどなんでバスなんて一言も言ってない俺が突っ込まれなきゃならないわけ？
ItaniumもSPARCもCPU単体の能力が低すぎてどうでもいいんですけど。
何でインターコネクトの帯域にそんなにこだわるの？
OpteronだったらNUMAだしCPU性能もSPARCの数倍あって満足なわけ？

[291 名無しさん＠お腹いっぱい。 2008/12/03(水) 13:50:49]

>>288
そういう言葉の揚げ足取りするのやめなよ。
どういう意図でバスと言ってるのか理解できるだろ。

[292 名無しさん＠お腹いっぱい。 2008/12/03(水) 13:53:46]

>>290
CPU単体の能力が低すぎる
↓
多数のCPUをSMPで動かす
↓
インターコネクトの性能で決まる

ってことかと。
Sunが真っ先にクロスバーを導入したとき、
そのCPU搭載数は競合他社の2倍だったと思う。

[293 名無しさん＠お腹いっぱい。 2008/12/03(水) 13:57:18]

で、だ。

CPU単体の能力が高ければ、
多数のCPUをSMPで動かす必要もなく、
ゆえにインターコネクトの性能も必要ない

[294 名無しさん＠お腹いっぱい。 2008/12/03(水) 13:59:53]

>>289
> すでにXeonはクロスバーになった、という話なんだがなぁ。

ほぉおふぉぉ、次はそう来るかよw んじゃ、QPIって、何?
オレって釣られまくり?

[295 名無しさん＠お腹いっぱい。 2008/12/03(水) 14:00:48]

>>293
それはさすがにバカ丸だしwwww Itaniumサイコー!!!!!!w

[296 名無しさん＠お腹いっぱい。 2008/12/03(水) 14:05:08]

>>290
> OpteronだったらNUMAだしCPU性能もSPARCの数倍あって満足なわけ？

SPARCナメてもらっちゃ困るな。SPARC64はシングルスレッド性能でもトップクラス。

[297 290 2008/12/03(水) 14:07:06]

いっとくけど俺は293じゃないからな。
ItaniumはSPARCより駄目だと思ってるし

[298 名無しさん＠お腹いっぱい。 2008/12/03(水) 14:09:59]

盛り上がってきたなぁ...ww
今何人参加してんだろp

[299 名無しさん＠お腹いっぱい。 2008/12/03(水) 14:14:18]

>>292
うちでOracle RAC使った実アプリで検証した結果は
SPARC III cu 24wayとOpteron 16wayでOpteronの方が1.8倍くらい
速かった。OracleライセンスやSANを入れた構築費は1/5くらい。
DBの話だから計算屋さんとは全然違った判断だと思うけど。
Opteronだとインターコネクトの帯域でこだわってる話題に
そぐわなくてすまんな。

Opteron 8CPU x2(RACノードとして)を超える必要が無いと
SPARCやItaniumは要らない。超える規模だと評価機借りるのも大変で
ベンダーの力も借りないといけないから、ベンダーのおすすめで
supredome/Fire x0Kクラスを評価して納得のいく性能が出たらそれを買う、という
流れになる。帯域がどうこうとかはいろいろある検討科目の一つに過ぎなくて
どうしてそんなにこだわる人がいるのか逆に疑問だ

[300 名無しさん＠お腹いっぱい。 2008/12/03(水) 14:17:31]

>>296
SPARC64ねえ、それは確かにいいかもしれない。
機会があったら評価してみたい。富士通には縁が無いんだけど。
やっぱSPARC IV+より全然いいの？つかItaniumスレでする
話じゃないな

[301 名無しさん＠お腹いっぱい。 2008/12/03(水) 14:24:15]

CINT2006
ASUSTeK Computer Inc. Asus P6T Deluxe (Intel Core i7-965 Extreme Edition) 33.6 30.2
Fujitsu Limited Fujitsu SPARC Enterprise M3000 12.6 11.5

[302 名無しさん＠お腹いっぱい。 2008/12/03(水) 14:35:09]

p5も評価してみたいなあ。
でもアレだよね、今から評価するならCore i7ベースのXeonも
楽しみだよね。そういやXeonとItaniumでソケット共通にするって
話はどこいったの？あれが完成してればItanium用サーバーに
Xeon差したりもできたの？ってできないと意味ないか。
チップセットとかいろいろ考えたらいっそのことXeonをエンタープライズまで
対応できるようにすりゃいいじゃんって思わないでもない

[303 名無しさん＠お腹いっぱい。 2008/12/03(水) 14:39:16]

>>294
QPIは、次の手。

FSBを4本、スヌープキャッシュ、FB-DIMMをデュアルチャネル2系統
ここまでは1チップに押し込むことはできたが、それ以上は厳しい。
かといって、このままでは、8コアや8ソケットはスケールしない。
だからQPI

[304 名無しさん＠お腹いっぱい。 2008/12/03(水) 14:39:55]

とりあえず両方とも QPIになって、その次。
それまで Itanium系の開発が今の勢いで続いてれば、の話だけどw

[305 名無しさん＠お腹いっぱい。 2008/12/03(水) 14:45:07]

>>302
Itaniumとソケット共通化で開発されていたXeonはキャンセルされて、従来通りのFSBのものが市場投入されました。
その後どうなったのかは、知らない。

だが、ソケット共通化しても、CPUだけをItaniumとXeonで交換できるとは思えない。

[306 名無しさん＠お腹いっぱい。 2008/12/03(水) 14:45:44]

>>299
> SPARC III cu 24wayとOpteron 16wayでOpteronの方が1.8倍くらい

Hypertransportは共通バスじゃない。

> ベンダーの力も借りないといけないから、ベンダーのおすすめで

その「ベンダー」に扱ってもらうには、そこそこの性能が必要。

[307 名無しさん＠お腹いっぱい。 2008/12/03(水) 14:48:50]

>>303
それ見ろ。今の Xeonは付け焼き刃対策してあるだけで、クロスバーへの
移行が必至なんじゃんか。そっちこそ往生際悪いぞ。

[308 名無しさん＠お腹いっぱい。 2008/12/03(水) 14:52:55]

>>305
> だが、ソケット共通化しても、CPUだけをItaniumとXeonで交換できるとは思えない。

Itaniumが邪魔になってる Intelとしては、

（ちょっとムリあったけど、がんばって）ソケット共通化しました
↓
性能も近いし、あんまり差別化できる点もないので、もう 1種類でいいですよね?

という大義名分で Itaniumを葬り去る絶好のシナリオ。

[309 名無しさん＠お腹いっぱい。 2008/12/03(水) 14:58:44]

葬り去るっていうかIPFにいっちゃったPentium開発チームを
メインストリームのCoreに戻す策略だろうか。
しかもhp(元Alpha)の開発者というおまけつきで

確か元々Pentium開発2チーム、モバイルがイスラエル1チームで
IPFに1チームとられて、イスラエルチームがメインも作るように
なったんだよね？

まあうまいことAMDと競争してくれて価格性能比のいいCPUが
バンバンでてくれば裏事情なんかどうでもいいけど

[310 名無しさん＠お腹いっぱい。 2008/12/03(水) 15:05:31]

>>307
QPIはクロスバーじゃないだろ。

で、段階的な進歩を付け焼き刃と言うのなら、Sunの第5世代E15Kも付け焼き刃だった、ってことになるぞ。
第4世代の6800らと同じCPU&メモリボードのアドレスを直に繋がずにスヌープフィルタ入れたのだから。
Xeonでスヌープフィルタを導入したのと同じことだぞ。

付け焼き刃だとしても、その時々に必要な性能を実現していれば、それでいいと思う。
むしろ、付け焼き刃もできずに、その時々に必要な性能を提供できなければ市場から脱落するし。

[311 名無しさん＠お腹いっぱい。 2008/12/03(水) 15:08:45]

Sunの第四世代までと、第五世代のCPUボード内は、アドレスがクロスバーではなく、帯域を共有している
これは理解してもらえたかな?

Sunは6800のセールストークとして、
24ものプロセッサがフラットにアドレスを共有して素晴らしく低レイテンシなのは他にはない
といってたけど、たしかにキャッシュのヒット率が高い用途では、それは素晴らしいことなのかも。
・・・って言うと、Intelの共有バスにも当てはまる褒め言葉になっちゃうな。

[312 名無しさん＠お腹いっぱい。 2008/12/03(水) 15:08:59]

Sun で言えば Mbus→UPAの段階だろ。
そんなんといっしょくたにされてたまるかw

[313 名無しさん＠お腹いっぱい。 2008/12/03(水) 15:15:11]

>>312
いや、違うな、UPAより前の、MBus+XDBusの段階だ。

ttp://jp.sun.com/products/wp/UEarch/docs/UEARC02.html

[314 名無しさん＠お腹いっぱい。 2008/12/03(水) 15:52:53]

SUNスレでどうぞ

[315 名無しさん＠お腹いっぱい。 2008/12/03(水) 15:53:54]

>>312-313
おいおい。

UPAはアドレスはブロードキャストだぞ。
SunでアドレスのブロードキャストしないのはFirePlaneにSSMを組み合わせた場合。

[316 名無しさん＠お腹いっぱい。 2008/12/03(水) 15:59:42]

メモリは別として、

FirePlaneのボードにUltraSPARC IIIを4つ積んだもの → 4コアXeonのCPUに相当
それをアドレスをブロードキャストで繋いだSun Fire 6800 → 4コアXeonを同一FSBに4つぶら下げたものに相当
アドレスのブロードキャストドメインを分割してスヌープフィルタで繋いだSun Fire 15K → 4コアXeonを個別のFSBで接続する7300チップセットのシステムに相当

Intelは常に他社の後追いですね。

[317 名無しさん＠お腹いっぱい。 2008/12/03(水) 16:01:37]

もひとつ、

AMDのHyperTransport → IntelのQPI

猿まねも、ここまでくると呆れるを通り越す。
しかし、素直に進化の王道を進んでいるだけ、あるいは、業界トレンド、っていう好意的な見方もできなくはない。

[318 名無しさん＠お腹いっぱい。 2008/12/03(水) 16:07:01]

>>315
いやいや。MBusに CPU4発。これを XDBusバックプレーンに接続。
1990年代初頭の技術だな。

[319 名無しさん＠お腹いっぱい。 2008/12/03(水) 19:23:54]

>>318
そいつはスヌープフィルタなんか持ってないんだが。

[320 名無しさん＠お腹いっぱい。 2008/12/03(水) 19:26:06]

いまだにクロスバー信者は、キャッシュのスヌープを理解してないのか。

[321 名無しさん＠お腹いっぱい。 2008/12/04(木) 09:32:17]

アホか。スヌープせずに MPがまともな性能で動くかwww んなもんクロスバーかどうかと
関係ないわい。
なんぼスヌープフィルタの効果が大きくても、それで「バスで OK」という
話にはならんだろうが。いつまで詭弁を弄するつもりよ?

[322 名無しさん＠お腹いっぱい。 2008/12/04(木) 10:46:56]

興奮してる

[323 名無しさん＠お腹いっぱい。 2008/12/04(木) 11:02:50]

>>321
スヌープの意味、わかってないね?
スヌープしなかったらキャッシュのコヒーレンシを実現できない。

> なんぼスヌープフィルタの効果が大きくても、それで「バスで OK」という
> 話にはならんだろうが。

SunのFirePlaneは、4プロセッサ単位でスヌープのドメイン(バスに相当)を構成し、
ドメイン間の通信をスヌープフィルタによってブロードキャストからポイントtoポイントに変えることで、
飛躍的なシステム性能の向上を実現したのですが、それはドメインに4プロセッサまでならOK
という話なんですよ。

[324 名無しさん＠お腹いっぱい。 2008/12/04(木) 11:36:55]

もうループに入りました。

..スヌープの意味わからずに SMPの話ができるわけないだろ。
Intelの言うことなんでもありがたくご拝聴してるからそんな偏った知識になる。
MBusにはスヌープの仕掛けがないとでも思ってるのか?

[325 名無しさん＠お腹いっぱい。 2008/12/04(木) 11:38:52]

>>323
そんでもも一回だけ。

> 飛躍的なシステム性能の向上を実現したのですが、それはドメインに4プロセッサまでならOK

それが「付け焼き刃」だ、といってる。クロスバーみたいな根本対処と
いっしょにすな、と。

[326 名無しさん＠お腹いっぱい。 2008/12/04(木) 11:44:47]

クロスバーと１回発言すると、どこからかお金が貰えるの？
なら俺も書こうかな。

[327 名無しさん＠お腹いっぱい。 2008/12/04(木) 12:12:35]

「スヌープフィルター」は、金貰えるのか?

[328 名無しさん＠お腹いっぱい。 2008/12/04(木) 12:33:17]

>>324
なんかね、>>321はスヌープフィルタのつもりでスヌープと言ってるっぽいのよ。

>>325
つまり、SunのFireplaneは、
「クロスバーみたいな根本対処といっしょに」できない「付け焼き刃」だって言いたいのね。

[329 名無しさん＠お腹いっぱい。 2008/12/06(土) 11:05:00]

328でFAだな

言葉が通じているようで通じていない人と話をすることほど無駄なものはない。

[330 名無しさん＠お腹いっぱい。 2008/12/08(月) 12:04:28]

Sun信者が無知だってことが明らかになりました

[331 名無しさん＠お腹いっぱい。 2008/12/17(水) 03:08:26]

このスレ久しぶりに来たけどこの話題何回繰り返すんだろうなｗ

[332 名無しさん＠お腹いっぱい。 2008/12/17(水) 05:01:14]

>>331
それは構って欲しいですっていう意味か?

[333 名無しさん＠お腹いっぱい。 2008/12/17(水) 09:41:45]

「そっとしといてほしい」みたいだぜ。たとえ話題皆無でもw

[334 名無しさん＠お腹いっぱい。 2008/12/17(水) 12:44:29]

Sunの糞信者に荒らされるよりは、何も話題がないほうがマシ。

[335 名無しさん＠お腹いっぱい。 2008/12/17(水) 13:37:33]

なんか話題ないの?

[336 名無しさん＠お腹いっぱい。 2008/12/18(木) 00:55:53]

話題無いって言う話題ぐらいしかないねぇ。。。

[337 名無しさん＠お腹いっぱい。 2008/12/18(木) 01:06:54]

Itaniumを仕事で使っているような人は、いまどき2chなんかやらんだろ。

昔は2chにプロがゴロゴロしていて有益な情報交換がなされていたようだが。

[338 名無しさん＠お腹いっぱい。 2008/12/18(木) 01:17:34]

4Q08に発表するという話だったのにまた遅延かという話題ならある

[339 名無しさん＠お腹いっぱい。 2008/12/18(木) 13:09:47]

夢がふくらまないな...w

[340 名無しさん＠お腹いっぱい。 2008/12/18(木) 13:20:17]

>>337
「昔」には 2chなんて「ない」と思うがww

[341 名無しさん＠お腹いっぱい。 2008/12/18(木) 17:06:44]

2chの昔な。

[342 名無しさん＠お腹いっぱい。 2008/12/18(木) 18:24:58]

Itaniumってコンパイラがもっと進化すれば爆発的に早くなるはずじゃなかったの？
もしかして「早すぎたんだ・・・」っていうやつなの？

[343 名無しさん＠お腹いっぱい。 2008/12/18(木) 19:00:16]

x86が爆発的に性能向上してしまったので霞んでしまっただけです。

とはいえ初代のMercedは遅かった。
1年後に出たMcKinleyはは速かった。
クロックはたったの1割しか速くなってないのだが、スピードがまるで違った。

[344 名無しさん＠お腹いっぱい。 2008/12/18(木) 19:06:18]

i860の Wikipediaにはこう書いてある。

| ...i860のデザインはこういったことをコンパイラが効果的に行うことを
| 前提としていて、それは不可能だったことが実証されている。

EPICは、どうかなww

[345 名無しさん＠お腹いっぱい。 2008/12/18(木) 19:33:37]

>>344
おまえ、i860のアーキテクチャを理解してないだろ。

Wikipediaのその説明はパイプラインモードについてのものだよ。

[346 名無しさん＠お腹いっぱい。 2008/12/18(木) 21:41:38]

>>342
最近ではHP-UX 11iV3で結構速くなったよ。
ただCPUがMontecitoのままじゃねえ。。。
コンパイラが神の様に賢くても理論演算性能を超えることは決してないからさ。

[347 名無しさん＠お腹いっぱい。 2008/12/18(木) 22:46:44]

HPはさ、PA-RISCもベンチマークだけは速いけど実際は・・・っていうシロモノだったから、
IA-64になってもショックが小さいと思うんだわ。

[348 名無しさん＠お腹いっぱい。 2008/12/18(木) 23:33:40]

Tukwila最強！

[349 名無しさん＠お腹いっぱい。 2008/12/18(木) 23:44:30]

SPARCはベンチマークは駄目だけど、実際は・・・だけどな。。

[350 名無しさん＠お腹いっぱい。 2008/12/18(木) 23:52:03]

SPARC最弱！

[351 名無しさん＠お腹いっぱい。 2008/12/19(金) 00:03:15]

Sun信者ウザイよ。Sunの話はSunスレでやれよ。

[352 名無しさん＠お腹いっぱい。 2008/12/19(金) 00:23:02]

そうだ、そうだ！

[353 名無しさん＠お腹いっぱい。 2008/12/19(金) 02:14:45]

TukwilaもRockに対抗して250Wバージョンを出すべき！

[354 名無しさん＠お腹いっぱい。 2008/12/19(金) 04:22:52]

ttp://www.anandtech.com/weblog/showpost.aspx?i=532
上の記事のせいで海外の掲示板に「Tukwilaも爆速なんじゃね?」とか言い出す厨房が氾濫しているから困る。

[355 名無しさん＠お腹いっぱい。 2008/12/19(金) 11:08:15]

>351
あわれだなぁ.. ここは Sunのとこから派生してできたんだって何度言えば..
Itaネタで埋まるくらい書いたらどうよ?