ItaniumをUNIXで使うスレ
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2008/07/14(月) 19:44:39前スレ
ItaniumでUNIX!
http://pc11.2ch.net/test/read.cgi/unix/1140329582/
0228名無しさん＠お腹いっぱい。
2008/11/29(土) 07:59:50そんなに気にしない。台数少ないにこしたことはないけどね。管理も楽だし。
DBはOracle RACいれてとりあえずノード追加で対応できて将来はまた
新しいH/W出てますから、って言う。まあDBはOracleさえ走ればLinuxでも
Solarisでもhp-uxでもいいから見せ玉使う事もないけど。
0229名無しさん＠お腹いっぱい。
2008/11/29(土) 09:28:31SQL ServerはWindowsのみなので、Itaniumには頭が上がりません。
0230名無しさん＠お腹いっぱい。
2008/11/29(土) 09:52:28それ以前の「バス」はだめだよ「バス」は。お話にならん。
なんでこうおバカが多いのか。踊らされてほんとにアワレなこった。
0231名無しさん＠お腹いっぱい。
2008/11/29(土) 10:00:08妄想はいいから自分で実機で検証してからホザきなさい。
0232名無しさん＠お腹いっぱい。
2008/11/29(土) 10:06:27スケールするという記事でも探してこい。
「商品が出てる」で証明になんかなるかボケ。
ちなみにオレはクソおそい 80386のMP機は触ったことあるぞ。
単発の 80386パソコンの何倍も遅かったが、製品だった。
まーーーーったく売れなかったと聞いてるww
0233名無しさん＠お腹いっぱい。
2008/11/29(土) 10:11:29その他には経験がないわけですねw
誇らしい経験をお持ちで良かったです。
>>227
皺々なんで見せるの恥ずかしいです（＞＜）
0234名無しさん＠お腹いっぱい。
2008/11/29(土) 10:36:13で、記事かなんか提示しろや。自分で買ってベンチしたのでもいいぞ。
ま、そんな知識じゃ SMPの評価なんてどうやったらいいかわからんだろうがなwwwwwww
0235名無しさん＠お腹いっぱい。
2008/11/29(土) 11:40:00Windows売るのにItaniumを見せ玉にってのは良く聞くな
でも、Becktonが出たらItaniumの役目も終わりだろ
Linuxで拡張性に不安って人は最初からUNIXに行くんじゃね？
0236名無しさん＠お腹いっぱい。
2008/11/30(日) 02:41:38置き換えられるようになるのはまだまだかかるんじゃないかな
0237名無しさん＠お腹いっぱい。
2008/11/30(日) 04:51:36退場。
0238名無しさん＠お腹いっぱい。
2008/12/01(月) 10:28:180239名無しさん＠お腹いっぱい。
2008/12/01(月) 14:40:06いいかげんにしろ。
0240名無しさん＠お腹いっぱい。
2008/12/01(月) 15:35:140241名無しさん＠お腹いっぱい。
2008/12/01(月) 15:46:110242名無しさん＠お腹いっぱい。
2008/12/01(月) 16:58:43自己矛盾君。
0243名無しさん＠お腹いっぱい。
2008/12/01(月) 17:15:46ま、もうゴミでも撒かなきゃ話題もないんだけどww
0244名無しさん＠お腹いっぱい。
2008/12/01(月) 17:32:53ttp://pc.watch.impress.co.jp/docs/2007/1113/hot515.htm
| ...このアライアンスを母体に新しく事業会社を起こし、そこにIA-64の設計や
| 開発を分離するのはどうだろう。...Tukwilaが完成し、QPIベースの
| プラットフォームが確立したら、タイミング的には頃合いだと思うのだが。
0245名無しさん＠お腹いっぱい。
2008/12/01(月) 17:41:480246名無しさん＠お腹いっぱい。
2008/12/01(月) 17:43:51国際イタニウム株式会社
0247名無しさん＠お腹いっぱい。
2008/12/02(火) 07:46:30これ、Sun Fireが4プロセッサを1つの共有バスに繋いでキャッシュスヌープしていたのと一緒。
そして、Xeon 7300や7400の4プロセッサ向けのチップセットではFSBが4本あり、
4つのプロセッサがFSBを共有せず、スヌープキャッシュによって、ほぼ独立している。
これらと2つの独立したメモリコントローラが、チップ上で密に結合されている。
これ、Sun Fireのボード間のクロスバースイッチをワンチップに納めたようなもの。
いまのXeonがSMPで性能が出ないというのなら、
かつてのSun FireのSMPも性能が出ないという話になる。
プロセッサ数あるいはコア数が倍になっても、性能は倍にはならないが、
それは、Sun Fireでも同じ。
0248名無しさん＠お腹いっぱい。
2008/12/02(火) 10:18:11バスなんか使ってないですが。直クロスバーですぜ。
んで、その Xeonの構成で、メインメモリはどこにつながってるの?
チップセットの先の「バス」よね?（そうじゃなきゃ NUMAだもんな）
んで、メインメモリへのアクセスは競合しないの?
バスが「飽和する」って、意味わかってる?
> これ、Sun Fireが4プロセッサを1つの共有バスに繋いでキャッシュスヌープしていたのと一緒。
> これ、Sun Fireのボード間のクロスバースイッチをワンチップに納めたようなもの。
> かつてのSun FireのSMPも性能が出ないという話になる。
> それは、Sun Fireでも同じ。
まぁーーーーーーっったく、違いますが。いっしょにしないでくれる?w
んで、その前にメモリのチャネル数とかも書いてたけど、それとバスの飽和と、
一体なんの関係があるわけ?
チャネル数増やして（見かけ上の）アクセス速度上げると、
バスは _余計に飽和_ しやすくなるけど?
バスが「飽和する」って、意味わかってる? （念の為 2回め）
0249名無しさん＠お腹いっぱい。
2008/12/02(火) 11:06:450250名無しさん＠お腹いっぱい。
2008/12/02(火) 11:35:16> Sun Fire（というか、UltraSPARC の IIiや IIIiじゃないやつ）は、
> バスなんか使ってないですが。直クロスバーですぜ。
データはクロスバーだけど、アドレスは実質的にバスだよ。
> んで、その Xeonの構成で、メインメモリはどこにつながってるの?
> チップセットの先の「バス」よね?（そうじゃなきゃ NUMAだもんな）
バスですよ。
> んで、メインメモリへのアクセスは競合しないの?
競合するよ。
メモリアクセスを開始できるのは同時に2つまで。
アドレスが実質的にバスのSun Fireも同じだよ。
メモリアクセスを開始できるのは同時に1つだけ。
> バスが「飽和する」って、意味わかってる?
アイドルサイクルがない状態が飽和、でしょう。
> んで、その前にメモリのチャネル数とかも書いてたけど、それとバスの飽和と、
> 一体なんの関係があるわけ?
独立して動作するメモリバスが2本あれば、
2つのコアのメモリアクセス要求を同時に処理できるので、
飽和した状態で処理できるメモリアクセスが増える。
0251名無しさん＠お腹いっぱい。
2008/12/02(火) 11:35:53いま自宅でRHEL3使ってるんだが、ぼちぼち入れ替えたい所。
ia64対応しているフリーのディストリで、今だったらどれがオススメ？
centosはいつまで経っても5系でないし、何かdebian位しかメンテされているのがない気がする。
0252名無しさん＠お腹いっぱい。
2008/12/02(火) 11:48:09> アドレスが実質的にバスのSun Fireも同じだよ。
おいおい。トンデモな言い訳はよしてくれや。
じゃ、バスに対するクロスバーの利点はなんだよ?
アドレスがバスだからクロスバーの利点は帳消しになるとでも? ふざけてんのか??
0253名無しさん＠お腹いっぱい。
2008/12/02(火) 12:10:34> おいおい。トンデモな言い訳はよしてくれや。
>>220のリンク先に書いてあることですが?
> じゃ、バスに対するクロスバーの利点はなんだよ?
クロックを低く抑えられ、ビット幅も小さくできるので、実装コストが安いことが利点だね。
もしSun Fireをバスにした場合、512bit幅でバスを配線しなくてはいけない。
クロスバーなら、発着が別の場合に、1つ前のメモリアクセスで生じた転送が終わる前に
次のメモリアクセスで生じる転送を開始できるので、つまり、転送をゆっくり行うことができる。
そのためSun Fireは128bit幅で4クロックに分けて転送してる。
0254名無しさん＠お腹いっぱい。
2008/12/02(火) 12:11:40いっそFreeBSDいってくれ。
0255名無しさん＠お腹いっぱい。
2008/12/02(火) 12:19:26使うだけならそのままRHEL3をEOL迄使いつづけたら？
開発に参加するならFedora9を入れるとか。
ttp://fedoraproject.org/wiki/Architectures/IA64
0256名無しさん＠お腹いっぱい。
2008/12/02(火) 12:19:54FreeBSD/ia64だとXが使えないのが苦しい所だな。
0257名無しさん＠お腹いっぱい。
2008/12/02(火) 12:28:22まさに使うだけだったからRHEL3で間に合ってたのだけど、
作業環境としては要らなくなったので、気分転換しようかと。
実験環境としてはdebianだと保守的すぎてつまらないし、
Fedora9で良さそうね。
0258名無しさん＠お腹いっぱい。
2008/12/02(火) 13:18:51> クロックを低く抑えられ、ビット幅も小さくできるので、実装コストが安いことが利点だね。
はぁ〜。どーしよーもねーな。
まあ、その程度じゃなきゃ共有バスで SMP性能が出るなんて思わんわな。
Wikipedia の「バス（コンピューター）のとこでも読んでみれ。話にならん。
| ...スター型トポロジとなるクロスバースイッチ（クロスバーバス）が
| ワークステーション等に採用されている。これは複数のCPU・メモリ間で
| 多対多の転送（通信）を同時に行えるようにしたもので、...
多対多で同時ね。は〜、疲れるわ。
0259名無しさん＠お腹いっぱい。
2008/12/02(火) 16:09:09こっちのほうが疲れるぞ。
思いっきり単純化して、スヌープとか調停とか端折りまくって説明するとだな。
■データ転送がクロスバーの場合、↓のようにデータ転送は多対多で同時に行えるので、
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に向けてデータ転送終了
0260名無しさん＠お腹いっぱい。
2008/12/02(火) 16:10:4464バイトの転送を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クロックで終わるなら、クロスバーにする意味はなくてバスでよい。
0261名無しさん＠お腹いっぱい。
2008/12/02(火) 16:35:39> 逆に言うと、データ転送が1クロックで終わるなら、クロスバーにする意味はなくてバスでよい。
あのなぁ........................ そういう前提がまちがってるし。
今 6coreが 4ソケットって話してるんだが、コアが 24という前提でやってくれるか?
1:4クロックでノード数 4て、日頃からそいういうインチキ語って暮らしてるの?
逆に言えば、上の例だと 5CPU以上ダメじゃん。実際オーバーヘッド入れたら
共有バスだと 4CPUもキツイ、というのにモロ符合するけどなw
オレもヒマだなw
0262名無しさん＠お腹いっぱい。
2008/12/02(火) 16:47:29> 逆に言えば、上の例だと 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に向けてデータ転送終了
0263名無しさん＠お腹いっぱい。
2008/12/02(火) 16:48:3464バイトの転送を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ノードで同じだよ?
0264名無しさん＠お腹いっぱい。
2008/12/02(火) 17:25:26> あのなぁ........................ そういう前提がまちがってるし。
クロックって言うからいけない
アドレスの1サイクルと同じ時間で終わるならって言えばいいのよ
0265名無しさん＠お腹いっぱい。
2008/12/02(火) 19:18:29転送は同時にできるが、その転送の要求は同時に出せない。
0266名無しさん＠お腹いっぱい。
2008/12/02(火) 20:01:360267名無しさん＠お腹いっぱい。
2008/12/02(火) 20:17:44かといってクロックを上げるのも大変だから、
そこで、
クロスバーですよ。
0268名無しさん＠お腹いっぱい。
2008/12/02(火) 20:30:30Xeon用のチップセットは、データ部分8.5GB/secのFSBを4本と、
送受信あわせて8GB/secのFB-DIMMを4チャネル(2チャネルずつ束ねて使われることに注意)、
合計66GB/secを、
クロスバーかバスか知らないが、とにかく、コンカレント動作を妨げないように接続している。
0269名無しさん＠お腹いっぱい。
2008/12/02(火) 22:37:56Sun 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のまま。
0270名無しさん＠お腹いっぱい。
2008/12/02(火) 23:16:55そりゃこの辺の知識があれば評価対象は絞り込みやすくていいけどさ、
いい加減お互いにけんか腰やめてくんないかな
0271名無しさん＠お腹いっぱい。
2008/12/02(火) 23:18:22保守入ってなきゃ新バージョンはもらえないのかな
0272251
2008/12/02(火) 23:57:25hp-uxは持ってないし、ドライバサポートに難があって、
確かVGAとSCSIボードを交換する必要があった。
シリアルコンソール＆ATA接続にすりゃ動く様だが、
それじゃあWSとは言えんわなｗ
ちなみにWindowsでもそのままの構成で動く。
0273名無しさん＠お腹いっぱい。
2008/12/03(水) 00:16:38どこの田舎の言葉ですか?
0274名無しさん＠お腹いっぱい。
2008/12/03(水) 01:19:530275名無しさん＠お腹いっぱい。
2008/12/03(水) 09:37:01え? バスバス言ってんのは、なんか反論でもした気になってるのかよ? 笑止
小手先の付け焼き刃の延命処置をさもまっとうな対策みたいに語るのは
よくあることだけどな。
0276名無しさん＠お腹いっぱい。
2008/12/03(水) 09:41:18まとめるとこういうことだな。
「なぜなら、クロスバーはアドレス指定がバスだからです。」
クロスバー導入したエンジニア達はそれに気付かなかったわけだw
0277名無しさん＠お腹いっぱい。
2008/12/03(水) 11:50:30↓
「バスを多段にして間にキャッシュ噛ます」
アドレスのバスを細かく分割して、スヌープフィルタを介して相互接続することで、ボトルネック解消
↓
Sun Fire 15K、従来の10倍以上の高速化を実現!
Xeon、共有バスなので飽和しまくり。
↓
バスを分割して、スヌープフィルタを介して接続することで、ボトルネック改善
ね、一緒でしょ。
>>273
真実には逆らえず、レッテル貼りによる封じ込めに作戦変更ですか?
0278名無しさん＠お腹いっぱい。
2008/12/03(水) 11:54:51> 通常のバス・アーキテクチャでは全ての信号が1本のバスを通るため、
> CPUなどを増やして処理性能を上げようとしてもバス性能が性能向上のボトルネックとなった。
> バスを流れる「データ」「コントロール」「アドレス」の3種類の信号のうち、
> データだけがクロスバー・テクノロジによって高速化されていた。
アドレスはバスでした。
もっと詳しいことは↓でも読んでくれ。
ttp://jp.sun.com/products/wp/server/WPcat4.pdf
0279名無しさん＠お腹いっぱい。
2008/12/03(水) 12:03:16原文はこちら
ttp://www.sc2001.org/papers/pap.pap150.pdf
0280名無しさん＠お腹いっぱい。
2008/12/03(水) 12:06:31> アドレスはバスでした。
お前の日本語をどうにかしろと
0281名無しさん＠お腹いっぱい。
2008/12/03(水) 12:11:16自分で持ち出しといて、内容を読んでなかったのかな。
0282名無しさん＠お腹いっぱい。
2008/12/03(水) 12:11:28性能がいいことを証明したことになる、のかよ? 無理あり過ぎだろw
実際そうなら 8コア超の Xeon MP機の評価記事がどんどん出てくるだろうし、
飛ぶように売れるだろうからそれでわかるんだろな。
じゃあ、QPIなんてやる必要はなかったわけだw
..どのみち Itaniumは-終了-なんだな。
0283名無しさん＠お腹いっぱい。
2008/12/03(水) 12:12:05アドレスは実質的にバス接続
これ、理解できないの?
0284名無しさん＠お腹いっぱい。
2008/12/03(水) 12:12:28あんた相手してるの元の人間と違うぞw
0285名無しさん＠お腹いっぱい。
2008/12/03(水) 12:14:41往生際が悪いぞ。
一部分でもバスだからダメというお前さんの主張を否定しただけだ。
0286名無しさん＠お腹いっぱい。
2008/12/03(水) 13:11:23クロスバーにすぐついてこれなかった RISCベンダーが打った対策の
焼き直しじゃないか。もっともらしく持って回ってあるが。
そいつら結局全部クロスバー行ってるし。
で、QPIはどうなんだよ? それ以上に素晴らしいバラ色の新技術か?w
0287名無しさん＠お腹いっぱい。
2008/12/03(水) 13:16:23> 一部分でもバスだからダメというお前さんの主張を否定しただけだ。
ところで、バスを分割して切り替え（スイッチング）して使うのは、
それはクロスバースイッチとは明確に違うのか? 信号線も減るんだろ?
粒度の違いで区別する?
0288名無しさん＠お腹いっぱい。
2008/12/03(水) 13:45:00アドレスリクエストがシェアードバスに流れると言いたいのか？
クロスバースイッチだって「バス」だぜ？
0289名無しさん＠お腹いっぱい。
2008/12/03(水) 13:48:09すでにXeonはクロスバーになった、という話なんだがなぁ。
>>287
Sunは、
> バスを分割して切り替え（スイッチング）して使う
ことも、クロスバーと呼んでるようですよ。
0290名無しさん＠お腹いっぱい。
2008/12/03(水) 13:50:41ItaniumもSPARCもCPU単体の能力が低すぎてどうでもいいんですけど。
何でインターコネクトの帯域にそんなにこだわるの？
OpteronだったらNUMAだしCPU性能もSPARCの数倍あって満足なわけ？
0291名無しさん＠お腹いっぱい。
2008/12/03(水) 13:50:49そういう言葉の揚げ足取りするのやめなよ。
どういう意図でバスと言ってるのか理解できるだろ。
0292名無しさん＠お腹いっぱい。
2008/12/03(水) 13:53:46CPU単体の能力が低すぎる
↓
多数のCPUをSMPで動かす
↓
インターコネクトの性能で決まる
ってことかと。
Sunが真っ先にクロスバーを導入したとき、
そのCPU搭載数は競合他社の2倍だったと思う。
0293名無しさん＠お腹いっぱい。
2008/12/03(水) 13:57:18CPU単体の能力が高ければ、
多数のCPUをSMPで動かす必要もなく、
ゆえにインターコネクトの性能も必要ない
0294名無しさん＠お腹いっぱい。
2008/12/03(水) 13:59:53> すでにXeonはクロスバーになった、という話なんだがなぁ。
ほぉおふぉぉ、次はそう来るかよw んじゃ、QPIって、何?
オレって釣られまくり?
0295名無しさん＠お腹いっぱい。
2008/12/03(水) 14:00:48それはさすがにバカ丸だしwwww Itaniumサイコー!!!!!!w
0296名無しさん＠お腹いっぱい。
2008/12/03(水) 14:05:08> OpteronだったらNUMAだしCPU性能もSPARCの数倍あって満足なわけ？
SPARCナメてもらっちゃ困るな。SPARC64はシングルスレッド性能でもトップクラス。
0297290
2008/12/03(水) 14:07:06ItaniumはSPARCより駄目だと思ってるし
0298名無しさん＠お腹いっぱい。
2008/12/03(水) 14:09:59今何人参加してんだろp
0299名無しさん＠お腹いっぱい。
2008/12/03(水) 14:14:18うちで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クラスを評価して納得のいく性能が出たらそれを買う、という
流れになる。帯域がどうこうとかはいろいろある検討科目の一つに過ぎなくて
どうしてそんなにこだわる人がいるのか逆に疑問だ
0300名無しさん＠お腹いっぱい。
2008/12/03(水) 14:17:31SPARC64ねえ、それは確かにいいかもしれない。
機会があったら評価してみたい。富士通には縁が無いんだけど。
やっぱSPARC IV+より全然いいの？つかItaniumスレでする
話じゃないな
0301名無しさん＠お腹いっぱい。
2008/12/03(水) 14:24:15ASUSTeK 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
0302名無しさん＠お腹いっぱい。
2008/12/03(水) 14:35:09でもアレだよね、今から評価するならCore i7ベースのXeonも
楽しみだよね。そういやXeonとItaniumでソケット共通にするって
話はどこいったの？あれが完成してればItanium用サーバーに
Xeon差したりもできたの？ってできないと意味ないか。
チップセットとかいろいろ考えたらいっそのことXeonをエンタープライズまで
対応できるようにすりゃいいじゃんって思わないでもない
0303名無しさん＠お腹いっぱい。
2008/12/03(水) 14:39:16QPIは、次の手。
FSBを4本、スヌープキャッシュ、FB-DIMMをデュアルチャネル2系統
ここまでは1チップに押し込むことはできたが、それ以上は厳しい。
かといって、このままでは、8コアや8ソケットはスケールしない。
だからQPI
0304名無しさん＠お腹いっぱい。
2008/12/03(水) 14:39:55それまで Itanium系の開発が今の勢いで続いてれば、の話だけどw
0305名無しさん＠お腹いっぱい。
2008/12/03(水) 14:45:07Itaniumとソケット共通化で開発されていたXeonはキャンセルされて、従来通りのFSBのものが市場投入されました。
その後どうなったのかは、知らない。
だが、ソケット共通化しても、CPUだけをItaniumとXeonで交換できるとは思えない。
0306名無しさん＠お腹いっぱい。
2008/12/03(水) 14:45:44> SPARC III cu 24wayとOpteron 16wayでOpteronの方が1.8倍くらい
Hypertransportは共通バスじゃない。
> ベンダーの力も借りないといけないから、ベンダーのおすすめで
その「ベンダー」に扱ってもらうには、そこそこの性能が必要。
0307名無しさん＠お腹いっぱい。
2008/12/03(水) 14:48:50それ見ろ。今の Xeonは付け焼き刃対策してあるだけで、クロスバーへの
移行が必至なんじゃんか。そっちこそ往生際悪いぞ。
0308名無しさん＠お腹いっぱい。
2008/12/03(水) 14:52:55> だが、ソケット共通化しても、CPUだけをItaniumとXeonで交換できるとは思えない。
Itaniumが邪魔になってる Intelとしては、
（ちょっとムリあったけど、がんばって）ソケット共通化しました
↓
性能も近いし、あんまり差別化できる点もないので、もう 1種類でいいですよね?
という大義名分で Itaniumを葬り去る絶好のシナリオ。
0309名無しさん＠お腹いっぱい。
2008/12/03(水) 14:58:44メインストリームのCoreに戻す策略だろうか。
しかもhp(元Alpha)の開発者というおまけつきで
確か元々Pentium開発2チーム、モバイルがイスラエル1チームで
IPFに1チームとられて、イスラエルチームがメインも作るように
なったんだよね？
まあうまいことAMDと競争してくれて価格性能比のいいCPUが
バンバンでてくれば裏事情なんかどうでもいいけど
0310名無しさん＠お腹いっぱい。
2008/12/03(水) 15:05:31QPIはクロスバーじゃないだろ。
で、段階的な進歩を付け焼き刃と言うのなら、Sunの第5世代E15Kも付け焼き刃だった、ってことになるぞ。
第4世代の6800らと同じCPU&メモリボードのアドレスを直に繋がずにスヌープフィルタ入れたのだから。
Xeonでスヌープフィルタを導入したのと同じことだぞ。
付け焼き刃だとしても、その時々に必要な性能を実現していれば、それでいいと思う。
むしろ、付け焼き刃もできずに、その時々に必要な性能を提供できなければ市場から脱落するし。
0311名無しさん＠お腹いっぱい。
2008/12/03(水) 15:08:45これは理解してもらえたかな?
Sunは6800のセールストークとして、
24ものプロセッサがフラットにアドレスを共有して素晴らしく低レイテンシなのは他にはない
といってたけど、たしかにキャッシュのヒット率が高い用途では、それは素晴らしいことなのかも。
・・・って言うと、Intelの共有バスにも当てはまる褒め言葉になっちゃうな。
0312名無しさん＠お腹いっぱい。
2008/12/03(水) 15:08:59そんなんといっしょくたにされてたまるかw
0313名無しさん＠お腹いっぱい。
2008/12/03(水) 15:15:11いや、違うな、UPAより前の、MBus+XDBusの段階だ。
ttp://jp.sun.com/products/wp/UEarch/docs/UEARC02.html
0314名無しさん＠お腹いっぱい。
2008/12/03(水) 15:52:530315名無しさん＠お腹いっぱい。
2008/12/03(水) 15:53:54おいおい。
UPAはアドレスはブロードキャストだぞ。
SunでアドレスのブロードキャストしないのはFirePlaneにSSMを組み合わせた場合。
0316名無しさん＠お腹いっぱい。
2008/12/03(水) 15:59:42FirePlaneのボードにUltraSPARC IIIを4つ積んだもの → 4コアXeonのCPUに相当
それをアドレスをブロードキャストで繋いだSun Fire 6800 → 4コアXeonを同一FSBに4つぶら下げたものに相当
アドレスのブロードキャストドメインを分割してスヌープフィルタで繋いだSun Fire 15K → 4コアXeonを個別のFSBで接続する7300チップセットのシステムに相当
Intelは常に他社の後追いですね。
0317名無しさん＠お腹いっぱい。
2008/12/03(水) 16:01:37AMDのHyperTransport → IntelのQPI
猿まねも、ここまでくると呆れるを通り越す。
しかし、素直に進化の王道を進んでいるだけ、あるいは、業界トレンド、っていう好意的な見方もできなくはない。
0318名無しさん＠お腹いっぱい。
2008/12/03(水) 16:07:01いやいや。MBusに CPU4発。これを XDBusバックプレーンに接続。
1990年代初頭の技術だな。
0319名無しさん＠お腹いっぱい。
2008/12/03(水) 19:23:54そいつはスヌープフィルタなんか持ってないんだが。
0320名無しさん＠お腹いっぱい。
2008/12/03(水) 19:26:060321名無しさん＠お腹いっぱい。
2008/12/04(木) 09:32:17関係ないわい。
なんぼスヌープフィルタの効果が大きくても、それで「バスで OK」という
話にはならんだろうが。いつまで詭弁を弄するつもりよ?
0322名無しさん＠お腹いっぱい。
2008/12/04(木) 10:46:560323名無しさん＠お腹いっぱい。
2008/12/04(木) 11:02:50スヌープの意味、わかってないね?
スヌープしなかったらキャッシュのコヒーレンシを実現できない。
> なんぼスヌープフィルタの効果が大きくても、それで「バスで OK」という
> 話にはならんだろうが。
SunのFirePlaneは、4プロセッサ単位でスヌープのドメイン(バスに相当)を構成し、
ドメイン間の通信をスヌープフィルタによってブロードキャストからポイントtoポイントに変えることで、
飛躍的なシステム性能の向上を実現したのですが、それはドメインに4プロセッサまでならOK
という話なんですよ。
0324名無しさん＠お腹いっぱい。
2008/12/04(木) 11:36:55..スヌープの意味わからずに SMPの話ができるわけないだろ。
Intelの言うことなんでもありがたくご拝聴してるからそんな偏った知識になる。
MBusにはスヌープの仕掛けがないとでも思ってるのか?
0325名無しさん＠お腹いっぱい。
2008/12/04(木) 11:38:52そんでもも一回だけ。
> 飛躍的なシステム性能の向上を実現したのですが、それはドメインに4プロセッサまでならOK
それが「付け焼き刃」だ、といってる。クロスバーみたいな根本対処と
いっしょにすな、と。
0326名無しさん＠お腹いっぱい。
2008/12/04(木) 11:44:47なら俺も書こうかな。
0327名無しさん＠お腹いっぱい。
2008/12/04(木) 12:12:35
■ このスレッドは過去ログ倉庫に格納されています