ItaniumをUNIXで使うスレ

1 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/14(月) 19:44:39 .net] 実際に使ってみた人、どうよ? 前スレ ItaniumでUNIX! pc11.2ch.net/test/read.cgi/unix/1140329582/ 261 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 13:18:51 .net] >>253 > クロックを低く抑えられ、ビット幅も小さくできるので、実装コストが安いことが利点だね。 はぁ〜。どーしよーもねーな。 まあ、その程度じゃなきゃ共有バスで SMP性能が出るなんて思わんわな。 Wikipedia の「バス（コンピューター）のとこでも読んでみれ。話にならん。 | ...スター型トポロジとなるクロスバースイッチ（クロスバーバス）が | ワークステーション等に採用されている。これは複数のCPU・メモリ間で | 多対多の転送（通信）を同時に行えるようにしたもので、... 多対多で同時ね。は〜、疲れるわ。 262 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 16:09:09 .net] >>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に向けてデータ転送終了 263 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 16:10:44 .net] ■データ転送がバスの場合、↓のようにデータ転送は同一のバスを時分割で行うので、 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クロックで終わるなら、クロスバーにする意味はなくてバスでよい。 264 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 16:35:39 .net] >>260 > 逆に言うと、データ転送が1クロックで終わるなら、クロスバーにする意味はなくてバスでよい。 あのなぁ........................ そういう前提がまちがってるし。 今 6coreが 4ソケットって話してるんだが、コアが 24という前提でやってくれるか? 1:4クロックでノード数 4て、日頃からそいういうインチキ語って暮らしてるの? 逆に言えば、上の例だと 5CPU以上ダメじゃん。実際オーバーヘッド入れたら 共有バスだと 4CPUもキツイ、というのにモロ符合するけどなw オレもヒマだなw 265 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 16:47:29 .net] >>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に向けてデータ転送終了 266 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 16:48:34 .net] ■データ転送がバスの場合、↓のようにデータ転送は同一のバスを時分割で行うので、 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ノードで同じだよ? 267 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 17:25:26 .net] >> 逆に言うと、データ転送が1クロックで終わるなら、クロスバーにする意味はなくてバスでよい。 > あのなぁ........................ そういう前提がまちがってるし。 クロックって言うからいけない アドレスの1サイクルと同じ時間で終わるならって言えばいいのよ 268 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 19:18:29 .net] >>258 転送は同時にできるが、その転送の要求は同時に出せない。 269 名前：名無しさん＠お腹いっぱい。 [2008/12/02(火) 20:01:36 .net] バスで 64バイトが 1クロックって、どういうことよ? 信号線 512本あるの? 270 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 20:17:44 .net] 信号線が512本もあったら実装が大変だし、 かといってクロックを上げるのも大変だから、 そこで、 クロスバーですよ。 271 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 20:30:30 .net] LSI内なら512本もOK Xeon用のチップセットは、データ部分8.5GB/secのFSBを4本と、 送受信あわせて8GB/secのFB-DIMMを4チャネル(2チャネルずつ束ねて使われることに注意)、 合計66GB/secを、 クロスバーかバスか知らないが、とにかく、コンカレント動作を妨げないように接続している。 272 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 22:37:56 .net] そろそろクロスバー盲信者にトドメ、さしとくかな。 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のまま。 273 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 23:16:55 .net] 16CPU超のシステムならアプリインストールしてベンチで評価するでしょ。 そりゃこの辺の知識があれば評価対象は絞り込みやすくていいけどさ、 いい加減お互いにけんか腰やめてくんないかな 274 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 23:18:22 .net] Itanium機にRHEL3って人はhp-uxはもっとらんの？ 保守入ってなきゃ新バージョンはもらえないのかな 275 名前：251 mailto:sage [2008/12/02(火) 23:57:25 .net] >>271 hp-uxは持ってないし、ドライバサポートに難があって、 確かVGAとSCSIボードを交換する必要があった。 シリアルコンソール＆ATA接続にすりゃ動く様だが、 それじゃあWSとは言えんわなｗ ちなみにWindowsでもそのままの構成で動く。 276 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 00:16:38 .net] > アドレスが実質的にバスなので どこの田舎の言葉ですか? 277 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 01:19:53 .net] 続きは検証センターででもやればいいのに。 278 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 09:37:01 .net] >>270 え? バスバス言ってんのは、なんか反論でもした気になってるのかよ? 笑止 小手先の付け焼き刃の延命処置をさもまっとうな対策みたいに語るのは よくあることだけどな。 279 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 09:41:18 .net] 「バスを多段にして間にキャッシュ噛ますとあら不思議、クロスバーに対抗できます。」 まとめるとこういうことだな。 「なぜなら、クロスバーはアドレス指定がバスだからです。」 クロスバー導入したエンジニア達はそれに気付かなかったわけだw 280 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 11:50:30 .net] Sun Fire 6800、アドレスが実質的にバスで飽和しまくり。 ↓ 「バスを多段にして間にキャッシュ噛ます」 アドレスのバスを細かく分割して、スヌープフィルタを介して相互接続することで、ボトルネック解消 ↓ Sun Fire 15K、従来の10倍以上の高速化を実現! Xeon、共有バスなので飽和しまくり。 ↓ バスを分割して、スヌープフィルタを介して接続することで、ボトルネック改善 ね、一緒でしょ。 >>273 真実には逆らえず、レッテル貼りによる封じ込めに作戦変更ですか? 281 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 11:54:51 .net] ttp://www.atmarkit.co.jp/news/200110/05/sun.html > 通常のバス・アーキテクチャでは全ての信号が1本のバスを通るため、 > CPUなどを増やして処理性能を上げようとしてもバス性能が性能向上のボトルネックとなった。 > バスを流れる「データ」「コントロール」「アドレス」の3種類の信号のうち、 > データだけがクロスバー・テクノロジによって高速化されていた。 アドレスはバスでした。 もっと詳しいことは↓でも読んでくれ。 ttp://jp.sun.com/products/wp/server/WPcat4.pdf 282 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 12:03:16 .net] ちなみに日本語訳は誤訳とかアヤシイ部分があるので、原文に当ったほうがいいかも。 原文はこちら ttp://www.sc2001.org/papers/pap.pap150.pdf 283 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 12:06:31 .net] >>278 > アドレスはバスでした。 お前の日本語をどうにかしろと 284 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 12:11:16 .net] ていうか、すでに>>220のURLに書いてあることなんだよな。 自分で持ち出しといて、内容を読んでなかったのかな。 285 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 12:11:28 .net] ...Sun Fireのクロスバーが性能改善した事実がすなわち今の Xeon MP機の 性能がいいことを証明したことになる、のかよ? 無理あり過ぎだろw 実際そうなら 8コア超の Xeon MP機の評価記事がどんどん出てくるだろうし、 飛ぶように売れるだろうからそれでわかるんだろな。 じゃあ、QPIなんてやる必要はなかったわけだw ..どのみち Itaniumは-終了-なんだな。 286 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 12:12:05 .net] >>280 アドレスは実質的にバス接続 これ、理解できないの? 287 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 12:12:28 .net] >>281 あんた相手してるの元の人間と違うぞw 288 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 12:14:41 .net] >>282 往生際が悪いぞ。 一部分でもバスだからダメというお前さんの主張を否定しただけだ。 289 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 13:11:23 .net] はあ? 往生なんかしませんが。ひょっとして追い詰めたとでも思ってるのか?! クロスバーにすぐついてこれなかった RISCベンダーが打った対策の 焼き直しじゃないか。もっともらしく持って回ってあるが。 そいつら結局全部クロスバー行ってるし。 で、QPIはどうなんだよ? それ以上に素晴らしいバラ色の新技術か?w 290 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 13:16:23 .net] >>285 > 一部分でもバスだからダメというお前さんの主張を否定しただけだ。 ところで、バスを分割して切り替え（スイッチング）して使うのは、 それはクロスバースイッチとは明確に違うのか? 信号線も減るんだろ? 粒度の違いで区別する? 291 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 13:45:00 .net] >>283 アドレスリクエストがシェアードバスに流れると言いたいのか？ クロスバースイッチだって「バス」だぜ？ 292 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 13:48:09 .net] >>286 すでにXeonはクロスバーになった、という話なんだがなぁ。 >>287 Sunは、 > バスを分割して切り替え（スイッチング）して使う ことも、クロスバーと呼んでるようですよ。 293 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 13:50:41 .net] 270だけどなんでバスなんて一言も言ってない俺が突っ込まれなきゃならないわけ？ ItaniumもSPARCもCPU単体の能力が低すぎてどうでもいいんですけど。 何でインターコネクトの帯域にそんなにこだわるの？ OpteronだったらNUMAだしCPU性能もSPARCの数倍あって満足なわけ？ 294 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 13:50:49 .net] >>288 そういう言葉の揚げ足取りするのやめなよ。 どういう意図でバスと言ってるのか理解できるだろ。 295 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 13:53:46 .net] >>290 CPU単体の能力が低すぎる ↓ 多数のCPUをSMPで動かす ↓ インターコネクトの性能で決まる ってことかと。 Sunが真っ先にクロスバーを導入したとき、 そのCPU搭載数は競合他社の2倍だったと思う。 296 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 13:57:18 .net] で、だ。 CPU単体の能力が高ければ、 多数のCPUをSMPで動かす必要もなく、 ゆえにインターコネクトの性能も必要ない 297 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 13:59:53 .net] >>289 > すでにXeonはクロスバーになった、という話なんだがなぁ。 ほぉおふぉぉ、次はそう来るかよw んじゃ、QPIって、何? オレって釣られまくり? 298 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 14:00:48 .net] >>293 それはさすがにバカ丸だしwwww Itaniumサイコー!!!!!!w 299 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 14:05:08 .net] >>290 > OpteronだったらNUMAだしCPU性能もSPARCの数倍あって満足なわけ？ SPARCナメてもらっちゃ困るな。SPARC64はシングルスレッド性能でもトップクラス。 300 名前：290 mailto:sage [2008/12/03(水) 14:07:06 .net] いっとくけど俺は293じゃないからな。 ItaniumはSPARCより駄目だと思ってるし 301 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 14:09:59 .net] 盛り上がってきたなぁ...ww 今何人参加してんだろp 302 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 14:14:18 .net] >>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クラスを評価して納得のいく性能が出たらそれを買う、という 流れになる。帯域がどうこうとかはいろいろある検討科目の一つに過ぎなくて どうしてそんなにこだわる人がいるのか逆に疑問だ 303 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 14:17:31 .net] >>296 SPARC64ねえ、それは確かにいいかもしれない。 機会があったら評価してみたい。富士通には縁が無いんだけど。 やっぱSPARC IV+より全然いいの？つかItaniumスレでする 話じゃないな 304 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 14:24:15 .net] 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 305 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 14:35:09 .net] p5も評価してみたいなあ。 でもアレだよね、今から評価するならCore i7ベースのXeonも 楽しみだよね。そういやXeonとItaniumでソケット共通にするって 話はどこいったの？あれが完成してればItanium用サーバーに Xeon差したりもできたの？ってできないと意味ないか。 チップセットとかいろいろ考えたらいっそのことXeonをエンタープライズまで 対応できるようにすりゃいいじゃんって思わないでもない 306 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 14:39:16 .net] >>294 QPIは、次の手。 FSBを4本、スヌープキャッシュ、FB-DIMMをデュアルチャネル2系統 ここまでは1チップに押し込むことはできたが、それ以上は厳しい。 かといって、このままでは、8コアや8ソケットはスケールしない。 だからQPI 307 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 14:39:55 .net] とりあえず両方とも QPIになって、その次。 それまで Itanium系の開発が今の勢いで続いてれば、の話だけどw 308 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 14:45:07 .net] >>302 Itaniumとソケット共通化で開発されていたXeonはキャンセルされて、従来通りのFSBのものが市場投入されました。 その後どうなったのかは、知らない。 だが、ソケット共通化しても、CPUだけをItaniumとXeonで交換できるとは思えない。 309 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 14:45:44 .net] >>299 > SPARC III cu 24wayとOpteron 16wayでOpteronの方が1.8倍くらい Hypertransportは共通バスじゃない。 > ベンダーの力も借りないといけないから、ベンダーのおすすめで その「ベンダー」に扱ってもらうには、そこそこの性能が必要。 310 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 14:48:50 .net] >>303 それ見ろ。今の Xeonは付け焼き刃対策してあるだけで、クロスバーへの 移行が必至なんじゃんか。そっちこそ往生際悪いぞ。 311 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 14:52:55 .net] >>305 > だが、ソケット共通化しても、CPUだけをItaniumとXeonで交換できるとは思えない。 Itaniumが邪魔になってる Intelとしては、 （ちょっとムリあったけど、がんばって）ソケット共通化しました ↓ 性能も近いし、あんまり差別化できる点もないので、もう 1種類でいいですよね? という大義名分で Itaniumを葬り去る絶好のシナリオ。 312 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 14:58:44 .net] 葬り去るっていうかIPFにいっちゃったPentium開発チームを メインストリームのCoreに戻す策略だろうか。 しかもhp(元Alpha)の開発者というおまけつきで 確か元々Pentium開発2チーム、モバイルがイスラエル1チーム� 313 名前：ﾅ IPFに1チームとられて、イスラエルチームがメインも作るように なったんだよね？ まあうまいことAMDと競争してくれて価格性能比のいいCPUが バンバンでてくれば裏事情なんかどうでもいいけど [] [ここ壊れてます] 314 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 15:05:31 .net] >>307 QPIはクロスバーじゃないだろ。 で、段階的な進歩を付け焼き刃と言うのなら、Sunの第5世代E15Kも付け焼き刃だった、ってことになるぞ。 第4世代の6800らと同じCPU&メモリボードのアドレスを直に繋がずにスヌープフィルタ入れたのだから。 Xeonでスヌープフィルタを導入したのと同じことだぞ。 付け焼き刃だとしても、その時々に必要な性能を実現していれば、それでいいと思う。 むしろ、付け焼き刃もできずに、その時々に必要な性能を提供できなければ市場から脱落するし。 315 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 15:08:45 .net] Sunの第四世代までと、第五世代のCPUボード内は、アドレスがクロスバーではなく、帯域を共有している これは理解してもらえたかな? Sunは6800のセールストークとして、 24ものプロセッサがフラットにアドレスを共有して素晴らしく低レイテンシなのは他にはない といってたけど、たしかにキャッシュのヒット率が高い用途では、それは素晴らしいことなのかも。 ・・・って言うと、Intelの共有バスにも当てはまる褒め言葉になっちゃうな。 316 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 15:08:59 .net] Sun で言えば Mbus→UPAの段階だろ。 そんなんといっしょくたにされてたまるかw 317 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 15:15:11 .net] >>312 いや、違うな、UPAより前の、MBus+XDBusの段階だ。 ttp://jp.sun.com/products/wp/UEarch/docs/UEARC02.html 318 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 15:52:53 .net] SUNスレでどうぞ 319 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 15:53:54 .net] >>312-313 おいおい。 UPAはアドレスはブロードキャストだぞ。 SunでアドレスのブロードキャストしないのはFirePlaneにSSMを組み合わせた場合。 320 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 15:59:42 .net] メモリは別として、 FirePlaneのボードにUltraSPARC IIIを4つ積んだもの → 4コアXeonのCPUに相当 それをアドレスをブロードキャストで繋いだSun Fire 6800 → 4コアXeonを同一FSBに4つぶら下げたものに相当 アドレスのブロードキャストドメインを分割してスヌープフィルタで繋いだSun Fire 15K → 4コアXeonを個別のFSBで接続する7300チップセットのシステムに相当 Intelは常に他社の後追いですね。 321 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 16:01:37 .net] もひとつ、 AMDのHyperTransport → IntelのQPI 猿まねも、ここまでくると呆れるを通り越す。 しかし、素直に進化の王道を進んでいるだけ、あるいは、業界トレンド、っていう好意的な見方もできなくはない。 322 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 16:07:01 .net] >>315 いやいや。MBusに CPU4発。これを XDBusバックプレーンに接続。 1990年代初頭の技術だな。 323 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 19:23:54 .net] >>318 そいつはスヌープフィルタなんか持ってないんだが。 324 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/03(水) 19:26:06 .net] いまだにクロスバー信者は、キャッシュのスヌープを理解してないのか。 325 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/04(木) 09:32:17 .net] アホか。スヌープせずに MPがまともな性能で動くかwww んなもんクロスバーかどうかと 関係ないわい。 なんぼスヌープフィルタの効果が大きくても、それで「バスで OK」という 話にはならんだろうが。いつまで詭弁を弄するつもりよ? 326 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/04(木) 10:46:56 .net] 興奮してる 327 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/04(木) 11:02:50 .net] >>321 スヌープの意味、わかってないね? スヌープしなかったらキャッシュのコヒーレンシを実現できない。 > なんぼスヌープフィルタの効果が大きくても、それで「バスで OK」という > 話にはならんだろうが。 SunのFirePlaneは、4プロセッサ単位でスヌープのドメイン(バスに相当)を構成し、 ドメイン間の通信をスヌープフィルタによってブロードキャストからポイントtoポイントに変えることで、 飛躍的なシステム性能の向上を実現したのですが、それはドメインに4プロセッサまでならOK という話なんですよ。 328 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/04(木) 11:36:55 .net] もうループに入りました。 ..スヌープの意味わからずに SMPの話ができるわけないだろ。 Intelの言うことなんでもありがたくご拝聴してるからそんな偏った知識になる。 MBusにはスヌープの仕掛けがないとでも思ってるのか? 329 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/04(木) 11:38:52 .net] >>323 そんでもも一回だけ。 > 飛躍的なシステム性能の向上を実現したのですが、それはドメインに4プロセッサまでならOK それが「付け焼き刃」だ、といってる。クロスバーみたいな根本対処と いっしょにすな、と。 330 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/04(木) 11:44:47 .net] クロスバーと１回発言すると、どこからかお金が貰えるの？ なら俺も書こうかな。 331 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/04(木) 12:12:35 .net] 「スヌープフィルター」は、金貰えるのか? 332 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/04(木) 12:33:17 .net] >>324 なんかね、>>321はスヌープフィルタのつもりでスヌープと言ってるっぽいのよ。 >>325 つまり、SunのFireplaneは、 「クロスバーみたいな根本対処といっしょに」できない「付け焼き刃」だって言いたいのね。 333 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/06(土) 11:05:00 .net] 328でFAだな 言葉が通じているようで通じていない人と話をすることほど無駄なものはない。 334 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/08(月) 12:04:28 .net] Sun信者が無知だってことが明らかになりました 335 名前：名無しさん＠お腹いっぱい。 [2008/12/17(水) 03:08:26 .net] このスレ久しぶりに来たけどこの話題何回繰り返すんだろうなｗ 336 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/17(水) 05:01:14 .net] >>331 それは構って欲しいですっていう意味か? 337 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/17(水) 09:41:45 .net] 「そっとしといてほしい」みたいだぜ。たとえ話題皆無でもw 338 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/17(水) 12:44:29 .net] Sunの糞信者に荒らされるよりは、何も話題がないほうがマシ。 339 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/17(水) 13:37:33 .net] なんか話題ないの? 340 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/18(木) 00:55:53 .net] 話題無いって言う話題ぐらいしかないねぇ。。。 341 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/18(木) 01:06:54 .net] Itaniumを仕事で使っているような人は、いまどき2chなんかやらんだろ。 昔は2chにプロがゴロゴロしていて有益な情報交換がなされていたようだが。 342 名前：名無しさん＠お腹いっぱい。 [2008/12/18(木) 01:17:34 .net] 4Q08に発表するという話だったのにまた遅延かという話題ならある 343 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/18(木) 13:09:47 .net] 夢がふくらまないな...w 344 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/18(木) 13:20:17 .net] >>337 「昔」には 2chなんて「ない」と思うがww 345 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/18(木) 17:06:44 .net] 2chの昔な。 346 名前：名無しさん＠お腹いっぱい。 [2008/12/18(木) 18:24:58 .net] Itaniumってコンパイラがもっと進化すれば爆発的に早くなるはずじゃなかったの？ もしかして「早すぎたんだ・・・」っていうやつなの？ 347 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/18(木) 19:00:16 .net] x86が爆発的に性能向上してしまったので霞んでしまっただけです。 とはいえ初代のMercedは遅かった。 1年後に出たMcKinleyはは速かった。 クロックはたったの1割しか速くなってないのだが、スピードがまるで違った。 348 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/18(木) 19:06:18 .net] i860の Wikipediaにはこう書いてある。 | ...i860のデザインはこういったことをコンパイラが効果的に行うことを | 前提としていて、それは不可能だったことが実証されている。 EPICは、どうかなww 349 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/18(木) 19:33:37 .net] >>344 おまえ、i860のアーキテクチャを理解してないだろ。 Wikipediaのその説明はパイプラインモードについてのものだよ。 350 名前：名無しさん＠お腹いっぱい。 [2008/12/18(木) 21:41:38 .net] >>342 最近ではHP-UX 11iV3で結構速くなったよ。 ただCPUがMontecitoのままじゃねえ。。。 コンパイラが神の様に賢くても理論演算性能を超えることは決してないからさ。 351 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/18(木) 22:46:44 .net] HPはさ、PA-RISCもベンチマークだけは速いけど実際は・・・っていうシロモノだったから、 IA-64になってもショックが小さいと思うんだわ。 352 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/18(木) 23:33:40 .net] Tukwila最強！ 353 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/18(木) 23:44:30 .net] SPARCはベンチマークは駄目だけど、実際は・・・だけどな。。 354 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/18(木) 23:52:03 .net] SPARC最弱！ 355 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/19(金) 00:03:15 .net] Sun信者ウザイよ。Sunの話はSunスレでやれよ。 356 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/19(金) 00:23:02 .net] そうだ、そうだ！ 357 名前：名無しさん＠お腹いっぱい。 [2008/12/19(金) 02:14:45 .net] TukwilaもRockに対抗して250Wバージョンを出すべき！ 358 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/19(金) 04:22:52 .net] ttp://www.anandtech.com/weblog/showpost.aspx?i=532 上の記事のせいで海外の掲示板に「Tukwilaも爆速なんじゃね?」とか言い出す厨房が氾濫しているから困る。 359 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/19(金) 11:08:15 .net] >351 あわれだなぁ.. ここは Sunのとこから派生してできたんだって何度言えば.. Itaネタで埋まるくらい書いたらどうよ? 360 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/19(金) 11:11:15 .net] >>98-102 361 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/19(金) 11:38:07 .net] >>344 i860は、Itaniumと比べると、 意図と結果がはっきりしたすがすがしいプロジェクトだった。 CPUは消えたが、多くの豊かな結果が残った。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef