ItaniumをUNIXで使うスレ

1 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/14(月) 19:44:39 .net] 実際に使ってみた人、どうよ? 前スレ ItaniumでUNIX! pc11.2ch.net/test/read.cgi/unix/1140329582/ 201 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/10/02(木) 14:10:19 .net] 自分でマイクロソフトのサイトでも見たら? 202 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/10/02(木) 14:47:02 .net] なんでそんなに言いたくないわけ?wwww 恥しくて?w 203 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/10/02(木) 14:55:17 .net] いつもの粘着キチガイか 204 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/10/02(木) 16:10:24 .net] まあ、カトラーは最初っから Itaniumには批判的だったみたいだしね。 Athlonの部隊には DEC出の同僚がたくさん居るみたいだし。 最適化の手法が Alphaと同じでイケるとかなんとか。 仕方ないわな。 205 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/10/03(金) 05:20:03 .net] カトラーというかWindowsNTは最初の方針の中に、 マルチスレッド化してマルチプロセッサでスケールする というのがあったので、 シングルスレッド性能を追求するあまりに効率の劇悪な IA-64というのはアホらしかったのだろう。 206 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/10/03(金) 09:57:30 .net] そうかなぁ。オレは単なる同窓会趣味と、自分の過去の技術に対する 固執（よく言えば自負）なんじゃないかと思ってるがww DECにはそういう社風あったそうだし。社外技術を見下す姿勢。 EPICは HPから出たもんだから。 207 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/10/03(金) 12:56:36 .net] レジスタウィンドウが嫌いなんだよ!! 208 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/10/03(金) 13:10:08 .net] レジスタウィンドウは使いにくいよね。 209 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/10/03(金) 16:16:26 .net] それは違うな。ハマれば高速。 210 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/10/03(金) 19:35:02 .net] 実際のところ、ハマるのか? 211 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/10/04(土) 23:20:18 .net] おっ。いまちょうどハマったw 212 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/10/16(木) 13:29:39 .net] JR九州、NX7700iシリーズなど 16台に移行、って書いてあるな。 イマイチ図が小さすぎてよく見えんが。NX7700iが何台だろ? 213 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/10/18(土) 02:33:24 .net] メインは8CPU機を2台でクラスタ構成っぽい。 214 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/16(日) 11:11:57 .net] >>121 亀レスだが。 ネイティブだろうがエミュだろうが、同じバージョンである以上その中身が変わることは まずいんでないの？特に商用利用では。 (パッチによるバグ修正は除く) HP-UXに関しては、逆にパフォーマンスに関わる部分はネイティブ化してあるって ことなんだろうさ。 215 名前：名無しさん＠お腹いっぱい。 [2008/11/19(水) 01:54:25 .net] top500の中でItaniumを使ってるのが 1.8% EM64T, x86_64を合計すると85% 216 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/19(水) 11:18:06 .net] きゅーぴーIで x86の SMPがまともになったりしたら即死だね。 ま、その可能性は低いと思うがw 217 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/27(木) 09:37:41 .net] >>214 だから何? むしろ1.8%も残っていることのほうが驚きだよ。 >>215 はいはい、Sunスレから出張で荒らしに来て、おつかれさん。 6コアXeonの4ソケットが出た時点で、速度面では、もう終わってるよ。 それでもItaniumを使うのは、速度以外の要素を重視する客でしょう。 まぁ限られてると思いますけどね。 218 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/27(木) 10:30:57 .net] > 6コアXeonの4ソケットが出た時点で、速度面では、もう終わってるよ。 24コアを「バス」で主記憶に接続して、まともに性能出るわけがない。 キャッシュに収まる特殊用途除いて、な。あんた次元低すぎるんだよ。 なんでわざわざインターコネクトの名前あげてるかぐらい考えてよね。 考えても書かなくていいけどww > それでもItaniumを使うのは、速度以外の要素を重視する客でしょう。 そんな用途で実績のかけらもないアーキを使う意味なんかないでしょ。 企業判断的にチョンボして行き詰まってる「事情」があるとこ以外には 無価値と思うが。 219 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/27(木) 11:12:53 .net] やはりその口調、Sunスレから荒らしに来ている人か。 あなたの脳内では、まともに性能が出ないそうだが、 各社がサーバ作って出してるんだよねぇ。 220 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/27(木) 11:20:42 .net] Xeon 7400番台を採用した4Pサーバは、Sunもリリースしていたと思うが。 221 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/27(木) 18:55:12 .net] まあ、このへんにちょうどいい解説があるよ。3.な。 ttp://www.geocities.jp/andosprocinfo/wadai02/20020511.htm | コモンバス方式は追加のハードも少なく一番簡単ですが、 | ...多数のプロセサを使うシステムでは性能が飽和してしまいます。 超入門者向け 1980年代の基礎知識だけどな。MP評価する立場ならこんなん知らんと 話にならん。 222 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/28(金) 05:09:47 .net] >>217や>>220の脳内では、今もXeonは1つのバスに24コアが並列に繋がっていて、メモリも1chしかないらしい。 223 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/28(金) 09:38:14 .net] こういうお話しにならないアホウが x86の SMP機買ったりするんだろうなぁ.. ろくに検証もしないから問題にもならない、とw 224 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/28(金) 12:41:06 .net] いつも相手を馬鹿にした態度で書き込みをしている・・・そういう病人はスルーしましょう。 しかも現実が見えてないですからね。 225 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/28(金) 18:41:16 .net] よっぽど会社じゃ居場所ないんだろか(´・ω・｀) 226 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/29(土) 02:33:55 .net] > ろくに検証もしないから あれれ、脳内妄想で評価している人が、そんなこと言いますか? 227 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/29(土) 07:01:00 .net] 確かにマルチコアでの性能の上がり具合はx86の方が低そうだけど、 Opteron 8wayとItanium 4wayでOpteronの方が性能が上で価格も数分の一となれば Opteron選ぶよねえ。うちでItanium入れたのなんてsuper domeくらいだ。 x86だとDL785の8CPUが上限だから、それ以上欲しいときはItanium/SPARCを 検討する。2CPUや4CPUで十分なサーバーにはx86しか入れない。 228 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/29(土) 07:36:58 .net] 板違いになりますが、Windowsで仕事してます。 お客様は夢見がちで、現時点でWindows鯖で十分なことは理解していても、 将来の業務拡大にハードウェアのアップグレードで追い付けないことを心配されます。 そのときにItaniumにアップグレード可能だと説明すれば、だいたい納得されます。 実際にはx86ベースのシステムの性能向上のペースを上まわって成長した事例はなく、 Itaniumは見せ玉のまま終わっています。 x86 & Linuxの案件でも、Itaniumは見せ玉として使えませんか? 229 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/29(土) 07:59:50 .net] DB鯖以外はスケールアウトが可能になってるからサーバー単体の性能は そんなに気にしない。台数少ないにこしたことはないけどね。管理も楽だし。 DBはOracle RACいれてとりあえずノード追加で対応できて将来はまた 新しいH/W出てますから、って言う。まあDBはOracleさえ走ればLinuxでも Solarisでもhp-uxでもいいから見せ玉使う事もないけど。 230 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/29(土) 09:28:31 .net] Oracleはマルチプラットフォームでいいですね。 SQL ServerはWindowsのみなので、Itaniumには頭が上がりません。 231 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/29(土) 09:52:28 .net] キューぴーIは、少なくとも理屈の上ではリニアなスケールの可能性があるよね。 それ以前の「バス」はだめだよ「バス」は。お話にならん。 なんでこうおバカが多いのか。踊らされてほんとにアワレなこった。 232 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/29(土) 10:00:08 .net] >>230 妄想はいいから自分で実機で検証してからホザきなさい。 233 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/29(土) 10:06:27 .net] お前こそ 8コア超の x86サーバーがエンプラ用途でちゃんとリニアに スケールするという記事でも探してこい。 「商品が出てる」で証明になんかなるかボケ。 ちなみにオレはクソおそい 80386のMP機� 234 名前：ﾍ触ったことあるぞ。 単発の 80386パソコンの何倍も遅かったが、製品だった。 まーーーーったく売れなかったと聞いてるww [] [ここ壊れてます] 235 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/29(土) 10:11:29 .net] >>232 その他には経験がないわけですねw 誇らしい経験をお持ちで良かったです。 >>227 皺々なんで見せるの恥ずかしいです（＞＜） 236 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/29(土) 10:36:13 .net] ああ、あとは皆無だ。そんなもん買うバカにはとんとお目にかからん。 で、記事かなんか提示しろや。自分で買ってベンチしたのでもいいぞ。 ま、そんな知識じゃ SMPの評価なんてどうやったらいいかわからんだろうがなwwwwwww 237 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/29(土) 11:40:00 .net] >>227 Windows売るのにItaniumを見せ玉にってのは良く聞くな でも、Becktonが出たらItaniumの役目も終わりだろ Linuxで拡張性に不安って人は最初からUNIXに行くんじゃね？ 238 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/30(日) 02:41:38 .net] その頃にはItaも少しは進化してるだろうし、32/64CPUクラスをXeonで 置き換えられるようになるのはまだまだかかるんじゃないかな 239 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/11/30(日) 04:51:36 .net] >>234 退場。 240 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/01(月) 10:28:18 .net] 実績ないんだから、提示不能。そういうことだよな?ww 241 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/01(月) 14:40:06 .net] >>238 いいかげんにし 242 名前：ろ。 [] [ここ壊れてます] 243 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/01(月) 15:35:14 .net] お前がな。 244 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/01(月) 15:46:11 .net] x86けなされると、なんでそんなにくやしいの? どーでもいいんだけどさ.. 245 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/01(月) 16:58:43 .net] どーでもいいなら聞く必要もあるまい。 自己矛盾君。 246 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/01(月) 17:15:46 .net] ゴミ撒かれるのはどーでもよくないわけで。 ま、もうゴミでも撒かなきゃ話題もないんだけどww 247 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/01(月) 17:32:53 .net] 既に約 1年前に元麻布氏がこんなの書いてたんだね。 ttp://pc.watch.impress.co.jp/docs/2007/1113/hot515.htm | ...このアライアンスを母体に新しく事業会社を起こし、そこにIA-64の設計や | 開発を分離するのはどうだろう。...Tukwilaが完成し、QPIベースの | プラットフォームが確立したら、タイミング的には頃合いだと思うのだが。 248 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/01(月) 17:41:48 .net] じゃあそうします。 249 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/01(月) 17:43:51 .net] Itanium International 国際イタニウム株式会社 250 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 07:46:30 .net] Xeon 7300や7400ってのは、1プロセッサに4コアあるいは6コア。これが同一のFSBを共有。 これ、Sun Fireが4プロセッサを1つの共有バスに繋いでキャッシュスヌープしていたのと一緒。 そして、Xeon 7300や7400の4プロセッサ向けのチップセットではFSBが4本あり、 4つのプロセッサがFSBを共有せず、スヌープキャッシュによって、ほぼ独立している。 これらと2つの独立したメモリコントローラが、チップ上で密に結合されている。 これ、Sun Fireのボード間のクロスバースイッチをワンチップに納めたようなもの。 いまのXeonがSMPで性能が出ないというのなら、 かつてのSun FireのSMPも性能が出ないという話になる。 プロセッサ数あるいはコア数が倍になっても、性能は倍にはならないが、 それは、Sun Fireでも同じ。 251 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 10:18:11 .net] Sun Fire（というか、UltraSPARC の IIiや IIIiじゃないやつ）は、 バスなんか使ってないですが。直クロスバーですぜ。 んで、その Xeonの構成で、メインメモリはどこにつながってるの? チップセットの先の「バス」よね?（そうじゃなきゃ NUMAだもんな） んで、メインメモリへのアクセスは競合しないの? バスが「飽和する」って、意味わかってる? > これ、Sun Fireが4プロセッサを1つの共有バスに繋いでキャッシュスヌープしていたのと一緒。 > これ、Sun Fireのボード間のクロスバースイッチをワンチップに納めたようなもの。 > かつてのSun FireのSMPも性能が出ないという話になる。 > それは、Sun Fireでも同じ。 まぁーーーーーーっったく、違いますが。いっしょにしないでくれる?w んで、その前にメモリのチャネル数とかも書いてたけど、それとバスの飽和と、 一体なんの関係があるわけ? チャネル数増やして（見かけ上の）アクセス速度上げると、 バスは _余計に飽和_ しやすくなるけど? バスが「飽和する」って、意味わかってる? （念の為 2回め） 252 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 11:06:45 .net] Itaniumの話しようぜ 253 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 11:35:16 .net] >>248 > Sun Fire（というか、UltraSPARC の IIiや IIIiじゃないやつ）は、 > バスなんか使ってないですが。直クロスバーですぜ。 データはクロスバーだけど、アドレスは実質的にバスだよ。 > んで、その Xeonの構成で、メインメモリはどこにつながってるの? > チップセットの先の「バス」よね?（そうじゃなきゃ NUMAだもんな） バスですよ。 > んで、メインメモリへのアクセスは競合しないの? 競合するよ。 メモリアクセスを開始できるのは同時に2つまで。 アドレスが実質的にバスのSun Fireも同じだよ。 メモリアクセスを開始できるのは同時に1つだけ。 > バスが「飽和する」って、意味わかってる? アイドルサイクルがない状態が飽和、でしょう。 > んで、その前にメモリのチャネル数とかも書いてたけど、それとバスの飽和と、 > 一体なんの関係があるわけ? 独立して動作するメモリバスが2本あれば、 2つのコアのメモリアクセス要求を同時に処理できるので、 飽和した状態で処理できるメモリアクセスが増える。 254 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 11:35:53 .net] じゃあ、Itaniumの話で。 いま自宅でRHEL3使ってるんだが、ぼちぼち入れ替えたい所。 ia64対応しているフリーのディストリで、今だったらどれがオススメ？ centosはいつまで経っても5系でないし、何かdebian位しかメンテされているのがない気がする。 255 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 11:48:09 .net] >>250 > アドレスが実質的にバスのSun Fireも同じだよ。 おいおい。トンデモな言い訳はよしてくれや。 じゃ、バスに対するクロスバーの利点はなんだよ? アドレスがバスだからクロスバーの利点は帳消しになるとでも? ふざけてんのか?? 256 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 12:10:34 .net] >>252 > おいおい。トンデモな言い訳はよしてくれや。 >>220のリンク先に書いてあることですが? > じゃ、バスに対するクロスバーの利点はなんだよ? クロックを低く抑えられ、ビット幅も小さくできるので、実装コストが安いことが利点だね。 もしSun Fireをバスにした場合、512bit幅でバスを配線しなくてはいけない。 クロスバーなら、発着が別の場合に、1つ前のメモリアクセスで生じた転送が終わる前に 次のメモリアクセスで生じる転送を開始できるので、つまり、転送をゆっくり行うことができる。 そのためSun Fireは128bit幅で4クロックに分けて転送してる。 257 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 12:11:40 .net] >>251 いっそFreeBSDいってくれ。 258 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 12:19:26 .net] >>251 使うだけならそのままRHEL3をEOL迄使いつづけたら？ 開発に参加するならFedora9を入れるとか。 ttp://fedoraproject.org/wiki/Architectures/IA64 259 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 12:19:54 .net] >>254 FreeBSD/ia64だとXが使えないのが苦しい所だな。 260 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/12/02(火) 12:28:22 .net] >>255 まさに使うだけだったからRHEL3で間に合ってたのだけど、 作業環境としては要らなくなったので、気分転換しようかと。 実験環境としてはdebianだと保守的すぎてつまらないし、 Fedora9で良さそうね。 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より駄目だと思ってるし

---

---

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

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