- 1 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/14(月) 19:44:39 .net]
- 実際に使ってみた人、どうよ?
前スレ
ItaniumでUNIX!
pc11.2ch.net/test/read.cgi/unix/1140329582/
- 401 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 15:13:33 .net]
- ていうかSunはx86バイナリをSPARC上で実行する試み、やめちゃったの?
昔はやってたよね。
NiagaraとかRockがそんなに素晴らしい、スケールするのであれば、
x86バイナリをSPARC上で実行するサーバを出せば売れるだろう。
- 402 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 15:14:11 .net]
- RISCは高性能だね
それ以外のは生き残れなかった
- 403 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 15:16:47 .net]
- >>393
まるで間違い。それなら組込み機器も大規模 SMPも全部 x86になってるはず。
ところが、x86は実際にはパチョコン以外ではまるで使えない、用途限定石。
- 404 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 15:17:38 .net]
- >>396
VLIWって互換性を捨ててるアーキテクチャでしょ。
自分でmakeすりゃいいじゃんっていうオープンソース文化の人たちや、
互換性のために生の命令セットは見せないというアプローチ、
あるいは組込みなんだから、互換性とか関係ないねって分野でないと、
VLIWは難しい。
そのVLIWの問題点を解決した、VLIW風だがVLIWではないEPICは、
いまのところ長期にわたるバイナリ互換を確保できていると思う。
試していないが、現行のバイナリは初代Itaniumでも実行できるんじゃね?
バンドルの組み合わせが増えてる分は例外でエミュレーションで劇遅かもしれんが。
- 405 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 15:21:08 .net]
- >>396
Centaur Technologyを忘れないでください。
>>399
あなたは偏見と罵倒前提で曇った目で他人の書き込みを読むから、意図が理解できないのですよ。
x86のメモリアクセスのための命令がネックで大規模SMPの効率が悪いって示唆してるんですがね。
ちなみに組込みではx86は目立たないけど使われ続けてます。
私の目の前に有るDELLの液晶モニタはOSDコントローラがx86ですよ。
- 406 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 15:27:20 .net]
- そのケンタウロスは生きているのか死んでいるのか
- 407 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 15:35
]
- [ここ壊れてます]
- 408 名前：:29 .net mailto: >>397
> x86バイナリをSPARC上で実行するサーバを出せば売れるだろう。
ソフトウェアベースや、x86の載ったアドオンカードのものはあったけど
あまり売れなかった。Alphaでもあったし。Itaでも似たようなことやりかけた。
性能出ててもダメだったと思う。Itaは Intelがやってるって以外、
何も目新しいことはない。賭ける連中の気が知れんw [] - [ここ壊れてます]
- 409 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 15:42:57 .net]
- そりゃ安いか速いか少なくともどっちかは満たさないとねえ
- 410 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 15:55:38 .net]
- え? SunのNiagara2はXeonとは比べ物にならないほどコストパフォーマンスがいいんでしょ?
- 411 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 15:57:21 .net]
- x86は命令セットがスケールしない仕様なので、たとえSPARCの命令セットに変換してもスケールしないだろ。
- 412 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 16:09:32 .net]
- >>405
そういう意味ではない。あんたの思いつく程度のことは RISC WS陣営がとっくに
やったし、Itaもそれ以上のことはしていない。
当初 Intelが言ってた、「x86を置き換える」ことができなければ、
あまり存在意義があるとは思えない。
金持ってるから、今の位置付けのまま維持することは可能だろうけど。
株主につつかれなきゃ。
- 413 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 16:19:09 .net]
- >>401,406
なるほど! じゃ、その効率の悪い「メモリアクセス命令」を禁止したサブセットを
定義して、コンパイラーにスイッチ付ければすべて解決じゃん!!
すげーな、スケールしまくりの新 x86アーキ! 期待してるよw
:
もちろん、RISCに似ちゃったり. ...しないよね?wwww
- 414 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 16:28:24 .net]
- >>407
x86を置き換えれなかったからといって、存在意義がないとは言えん。
x86では届かない部分をカバーするという意味はあるし、
その領域でItaniumで経験したことや実績は、将来にx86がカバーするようになるための基礎になりえる。
>>408
別にコンパイルするなら、x86である必要ないじゃん。
最初からSPARCをターゲットにコンパイルすりゃいい。
Sun信者はいつも、意図的に間違った方向に話を持っていくね。
- 415 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 16:35:58 .net]
- >>409
> x86を置き換えれなかったからといって、存在意義がないとは言えん。
もちろん、「もう優秀な RISC ISAがたくさんあるんだから、」その上には
必要ない、という意味。
> x86では届かない部分をカバーするという意味はあるし、
> その領域でItaniumで経験したことや実績は、将来にx86がカバーするようになるための基礎になりえる。
それも同じ。わざわざ Itaでやらんでもよい。もうたくさんある。
> Sun信者はいつも、意図的に間違った方向に話を持っていくね。
はっはっはっはっ。君、おもしろいね?w
- 416 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 16:47:47 .net]
- >>410
Intelにとっては、というのは明記しなくても、読み取れるだろうが・・・
- 417 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 16:50:19 .net]
- アホか。その前のを読み取ってないのはオマエじゃw ほんとにオモロイなk
- 418 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 16:53:17 .net]
- はい>>412が誰かを煽ることを目的にスレに粘着していることを白状しました。以後スルー推奨。
- 419 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 16:58:21 .net]
- 「誰かを煽る」んじゃなくて、単にアホにアホと言ってるだけなんだが。
妄想ハゲしいねww
- 420 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 16:59:09 .net]
- なんつーか、この苦し紛れさ加減はwwww
- 421 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 17:09:36 .net]
- 消費電力が少なくてやっすいのを一台なんとか
- 422 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 17:12:10 .net]
- >>414-415
連投しないと気がすまない病?
- 423 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 17:43:01 .net]
- >>417
偽・スルー みんなにスルーを呼びかける。実はスルーできてない。
失敗スルー 我慢できずにレスしてしまう。後から「暇だから遊んでやった」などと負け惜しみ。
疎開スルー 本スレではスルーできたが、他スレでその話題を出してしまう。見つかると滑稽。
3つはあてはまるなww
ここからスルーできるかな〜?www おかしーw
- 424 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 17:48:51 .net]
- うれしそうですね
- 425 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 18:14:24 .net]
- >>399
>まるで間違い。それなら組込み機器も大規模 SMPも全部 x86になってるはず。
SMPサーバーで性能でないのはx86だからじゃないだろ・・・
Chip-to-Chip、あるいはBoard-to-BoardのInterconnectが安かったりネットワークのトポロジが不適切だからだ。
技術的にx86でやれないことはないんだよ。実際ItaniumとXeonMPでプロセッサバスとチップセットを互換にするしね。
競合のIBM POWERの強さや既に開拓したItanumの市場、そういった諸々の要素を勘案して見込みがないと判断したのだろう。
リスクとベネフィットを秤にかけたわけだ。
逆に組み込み向けではAtomで真剣に参入を始めたよ。儲かってたXScaleをも売却したのだから本気も本気さ。
達成できるか怪しいが目標は100億ドルの市場へ成長させることと言ってるよ。
SMPサーバー向けのCPUでこれだけの売り上げは見込めないよね。箱全部の値段ならともかくさ。
色々考えてから書き込もうよ。安易に「まるで間違い」とか言う前にさ。
- 426 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 18:20:13 .net]
- SPARC liteが組込みに使われていた・・・ってのも過去の話だよね。
そのうちAtom採用のデジカメとか、個人向けプリンタ・スキャナ複合機が出てくるだろうね。
そんな無駄だろ? って思うかもしれないが、開発のしやすさがまるで違うんだわ。
- 427 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/05(月) 22:47:24 .net]
- おまえら仕事しろ
- 428 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 09:53:30 .net]
- >>421
> 開発のしやすさがまるで違うんだわ。
そんなバカなww 「既存の xxがあるから」、だろ? そりゃ他知らんだけ。
- 429 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 10:17:57 .net]
- >>423
じゃぁ何でx86が組込みに使われてると思ってんだ?
- 430 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 13:31:40 .net]
- 「使われてる」なんて言うほど使われてないよ。80186の類はいっぱい使われてるけどな。
- 431 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 13:43:25 .net]
- SPARCとどっちが多い?
- 432 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 13:44:16 .net]
- 東芝のHD DVDレコーダーは、x86だったな。
80186とかそんな非力なのではなくて。
- 433 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 13:44:46 .net]
- だから失敗したのか
- 434 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 13:46:44 .net]
- そうだな。SPARCだったら大成功だったところだ。
- 435 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 13:50:17 .net]
- HD DVDプレーヤーにMobile Pentium4 2.54GHzが積まれててﾜﾛﾀ。
- 436 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 13:59:37 .net]
- そういうのはパソコンまるごとから削ったタイプのやつだな。
組込み全体から見たら僅かに過ぎんが.. もうひとくくりで語るべきじゃないだろな。
今後増えるだろし。
- 437 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 14:34:37 .net]
- Itaniumの話をしてください
- 438 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 16:19:03 .net]
- >>431
組込み全体の話なんかナンセンスだよ。
組込みのうちSPARCが使われている領域の話に限定しなよ。
NASなんかは、「パソコンまるごとから削ったタイプ」そのものだよ。
- 439 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 17:21:52 .net]
- 「x86に将来性なし」ってのは別にオレが言ったことでもなく、
ここの誰が言ったわけでもなく、Intelが言ったことなんだが。
なんでこう諦めが悪いかなww
んでもって、そんな x86の諦め悪いやつがなんでここにいるんだ?
amd64のデキがよかった、Meromのデキがよかった、Atomのデキがよかった、
そんなことが「x86の将来性」ないのを覆した、とか思ってるわけ?
先延ばししただけでしょ、どうヒイキ目に見ても。
- 440 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 17:40:40 .net]
- Intelが間違わないという保証があるわけじゃないな
- 441 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 17:52:44 .net]
- >>434
お前、なんで必死なんだ?
- 442 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 18:19:52 .net]
- 命令セットがどうこうってのは20年ほど前の議論だよな
結果から言えば当時の人たちはトレンドを読み外したということでFA
- 443 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 18:43:40 .net]
- 何の話してんの?
- 444 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 18:46:11 .net]
- 分からないなら黙ってればいいのに
- 445 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 18:47:11 .net]
- なんでそんなに必死なの? ..w
- 446 名前：432 [2009/01/06(火) 19:22:22 .net]
- Itaniumのことだけ書いてください
- 447 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 19:30:57 .net]
- Itaniumの話か。
AMDにIA-64を採用するように働きかけなかったIntel
IA-64を採用しようとしなかったAMD
この2社が、世界のパソコンの将来に大きな負債を残した
- 448 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 19:49:43 .net]
- そうだな。その後 IA-64がコケたとしても、今とは別の展開があっただろう。
あんまり期待できんがw
「両者それぞれ am29k, i960を復活、バークレーRISC乱立の混迷へ」...w
- 449 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 20:01:52 .net]
- IA-64の命令セットと、プロセッサの実装を、分けて考えないと。
技術力のないインテルの実装だからItaniumがアレなんであって、
技術力の優れたAMDが実装すればIA-64でありながら素晴らしい
プロセッサが出来あがっていたかもしれないぞ。
IA-64の、とりあえず実行して結果を捨てるのは消費電力的に無駄が多いが、
現状のx86の、複雑なデコードや、同時に実行できる命令を探したり・・・etcの消費電力も大きい。
IA-64の場合、実行ユニットを減らすことも可能で、SPARCのレジスタ数によるスケールよりは、よっぽどスケールする。
初代はともかくMckinley以降はさほど悪くない。
もしインテルがx86と同じだけのリソースを割いて最先端のプロセスで生産すれば、違ったことになってただろう
とはいえ、x86と同じだけのリソースを割くなんて、ありえない仮定だが。
- 450 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 20:27:44 .net]
- Itaniumの一番ダメな点 = レジスタウィンドウもどきを実装していること。
- 451 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 20:48:30 .net]
- Itaniumの一番ダメな点 = EPICじゃないの？
- 452 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 20:49:26 .net]
- 2001年頃にAMDが潰れてればx86からIA-64への強制的な移行が推進されたのかもな
今は”やっぱり命令セットは拡張できる方がイイヨネ！”って時代なのでありえない話
- 453 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 21:09:40 .net]
- Intelが用意していた(AMD64ではない)x86の64ビット拡張は、IA-64とは違うものだったらしいですよ。
- 454 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 21:10:51 .net]
- なんだかやる気のないやつね
- 455 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 21:35:18 .net]
- どうせAMDにペースを握られたくないという理由だけで策定した間に合わせのものだろう
あるいはx86_64よりIA-64のほうがいいよねって流れに誘導したかったんじゃないかと
- 456 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 21:40:39 .net]
- まあそれでもちゃんとキャッチアップしてCore2DuoとかCore i7出したんだから
結果的にはよかったんじゃないかな。
- 457 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 21:50:34 .net]
- それにしたってAMD64は、ヤッツケ仕事すぎる。
命令セットを大きく拡張あるいは変更できるチャンスというのは、
16→32ビット、32→64ビットの次は、64→128ビット・・・はないだろう。
だから、16→32ビットの時よりも遥かに将来を見通して策定すべき。
にもかかわらず、目先のことだけ考えた安易な拡張。これはひどい。
レジスタをすべて等価にするのではなく、2段階のコストにした点は評価できる。
良く使うレジスタは速く、あまり使わないレジスタは遅くというのは、
RISCが旗印にしていた定量的アプローチ、だものね。
- 458 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 21:54:06 .net]
- まあインテルさんがIA64とかにかまけてないでまじめに
x86の拡張をかんがえてればよかったんじゃないのかなー
まあ状況的に無理だけど
だから次善の策としてamd64はよかったんじゃないかな
- 459 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 21:55:59 .net]
- >>451
なんかIntelやばいんじゃね？と思ったら常勝の帝国軍へ戻っていた
な、なにを言ってるのかわからねーとおもうが(ry
- 460 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/06(火) 22:03:21 .net]
- x64だっけ?
アセンブラのニーモニックのレベルではx64のそれでいいとしても、
せめてオペコードなどの割り当ては真っ新からやり直すべきだった。
32ビットと64ビットでデコーダを共用できなくなるが、
だがしかし、ここでキレイに整理しておけば、後々かなり楽になる。
- 461 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/07(水) 07:04:56 .net]
- オペコードが人間が綺麗と感じるように割り当てられてることにどんな意味があるの？
- 462 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/07(水) 10:43:16 .net]
- > オペコードが人間が綺麗と感じるように
はいはい、意図的に誤解して架空の話を叩いて喜んでないで仕事しようね。
- 463 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/07(水) 10:43:26 .net]
- デコーダがシンプルになる...いまどきどうでもよいが。
将来の拡張の余地が広がる。これは大きい。
- 464 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/07(水) 10:45:34 .net]
- AVXでおk
- 465 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/07(水) 10:54:44 .net]
- AVX?
あれ長いよ。
たった1バイトしか短くならない・・・1バイトでも短くなることは重要ではあるし、
その次の拡張で長くならないことも重要なのだが、グダグダっしょ。
- 466 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/08(木) 15:11:25 .net]
- ほれ見ろ。オレがネタ投下してやんないとなんも出んがなw
- 467 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/08(木) 15:13:49 .net]
- 安くて消費電力の少ないIta2マシンどっかに落ちてないかな
中古でいいよ
- 468 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/10(土) 00:42:48 .net]
- そんな製品がないんだから中古なんてなおさらあるわけないw
複雑化の原因はコンパイラにまかせてコアは単純化されてるはずだから
キャッシュ減らしたら電力食わないんだろ、きっと。そうに違いないwww
- 469 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/10(土) 20:06:22 .net]
- キチガイはスルーで
- 470 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/10(土) 21:05:06 .net]
- >>433
NASとCPUと言えば、AuspexがSPARCでやっていたのを、
廉価NAS構成に対向しようとx86に移行しようとして失敗沈没してﾜﾛﾀ
コントローラはSolaris for x86で問題なかったけど、
独自ファームのエンジンがどうにもならなかったみたい。
やっぱCPU移行は慎重にやらないとね。
本当にメリットがあるのかどうか。どのCPUでも。
>>452
AMDはそういう路線だからしかたないんじゃ？
コストかけて研究部門維持するわけにもいかないし。
- 471 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/10(土) 21:23:58 .net]
- AMDを責めてもしかたないわな。
水先案内人としての責任は、牽引する立場のIntelにある
- 472 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/10(土) 21:28:21 .net]
- 市場を完全に制圧してからやるべきだったね
その辺Microsoftは賢い
- 473 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/10(土) 21:33:14 .net]
- AMDはIntelの失敗を修正する役割があると
- 474 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/10(土) 21:36:05 .net]
- >>452
Intelの最適化まぬあるによると増えたレジスタは使うなというｗ
- 475 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/10(土) 21:38:25 .net]
- あはははは
- 476 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/10(土) 22:12:26 .net]
- >>467
そのほうが消費者の利益になったとしても、独占ってだけで叩かれるぞ。
個人的にはAMDのIA-64実装を見てみたかった。
>>468
Intelを牽制する役割、だろうな。
>>469
IntelのCPUだと増えたレジスタを使った場合に、ガクンと遅くなるんだよな。
そりゃ、使うなと書いて当然だ。
こういう新しい命令セットってのは、互換性が重要なのよ。
最初にインプリしたCPUでは、速く実行できる必要はなくて、とにかく、正常に実行できることが重要。
その命令セットを実行できるCPUが市場に十分に出まわった時点で、本格的にソフトが使いはじめる。
この時点で、その命令セットを高速に実行できるCPUを市場に投入すればいいの。
まったく実行できない
と
遅いけど実行できる
というのでは、まるでインパクトが違う。
うまく移行するためには、早くから種まきしておかないと。
- 477 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/10(土) 22:22:44 .net]
- 命令長伸ばしてレジスタ拡張なんて最近流行の電力効率に反する実装だからだよ
AVXの目的もそういうことだ
- 478 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/10(土) 22:32:30 .net]
- やっぱり、64ビット拡張するときに、OPコードを大胆に整理すべきだったんだよ。
モードによって違うのはデコーダのコストが増えるが、
しかし、
命令長が長いのに比べたらマシだと思うんだわ。
もったいないよ。使わない命令が短くて、使う命令が長いのは。
- 479 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/14(水) 01:57:08 .net]
- なんか自作板にTukwilaはDDR3サポートに変更になったとか書き込みがあった。
- 480 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/14(水) 12:11:19 .net]
- そうなればそうなるわな
- 481 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/14(水) 12:58:33 .net]
- 以前からDDR3系のFB-DIMM2も対応予定に入ってなかったっけ？
それともFB-DIMM1のサポート無くしたという意味かな。
- 482 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/14(水) 16:18:08 .net]
- え?
FBってのは、DRAMチップのI/Fが変ってもOKっていう柔軟性も兼ね備えているんじゃないの?
- 483 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/14(水) 16:39:30 .net]
- 2007年の時点で、
DDR3を使ったFB-DIMMの提供予定はない
っていう話だった。
- 484 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/14(水) 16:40:48 .net]
- FB-DIMMやめて直にDDR3のメモリコントローラを積むって話では?
- 485 名前：474 mailto:sage [2009/01/14(水) 22:32:03 .net]
- >>478
そのあとFB-DIMMのバッファチップをマザーボードに置くとかいう話が出てきた。
そうするとスロットに挿すメモリはDDR3だけどMCHのインターフェースはFB-DIMMになる。
>>479
うん、そんな感じだった。
- 486 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/14(水) 23:08:59 .net]
- へー、直結にするんか。
まあ、その方がレイテンシ短くできるだろうし、やるかどうか怪しいけど
Xeon-MPとのプラットフォーム共通化も進めやすいだろうし。
それで発売が遅れてるんだったら、まあ建設的な理由だな。
- 487 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/15(木) 03:06:16 .net]
- そもそもFB-DIMMって、
メモリコントローラをチップセットに持たせた時に、
大量のメモリを積むためのもの。
チップセット1つから、メモリのバスを12本とか出せないんでね。
ところが
QPIを導入した時点で、
CPUの数だけメモリコントローラを増やすことができる。
メモリのバスを3本もつCPUを4ソケット構成にすれば、
無理なく12本のメモリバスが得られる。
- 488 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/15(木) 03:13:48 .net]
- DDRのままではコア数はどんどん増えるのに帯域はあまり稼げないしピン数も爆発的に増える。
シリアルメモリは絶対必要。なのにFB-DIMMは死んでDDR4はどんどん先送りされている。
Nehalemでは痛みに耐えて3chにしたけど1年後には6コアのWestmereが来る。焼け石に水。
高速なローカルメモリの使えるLarrabeeでどうにかなるという読みなのかね。
- 489 名前：483 mailto:sage [2009/01/15(木) 03:25:32 .net]
- 忘れていたが。。。Sandy Bridgeでon-package memoryとかいう噂もあったね。。。
SandyBridgeもNehalem同様processor coreのmicroarchitectureの変更は控えめでmemory回りの強化が主眼になる予感。
それでも十分new-architectureなのだけど。。。
ttp://www.intel.com/technology/itj/2007/v11i3/3-bandwidth/6-architectures.htm
これ、ItaniumでもPoulsonで採用されるのかな。コスト的なハードルはItaniumの方が低いと思うが。
- 490 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/15(木) 09:06:15 .net]
- >>483
Larrabeeは、普通のCPUを置き換えるようなものではないと思う。
少なくとも、エンタープライズのサーバのCPUの置き換えにはならない。
>>484
それは大容量のL3やL4のキャッシュを乗せようという話だと思います。
- 491 名前：483=484 mailto:sage [2009/01/15(木) 22:37:30 .net]
- >>485
>Larrabeeは、普通のCPUを置き換えるようなものではないと思う。
>少なくとも、エンタープライズのサーバのCPUの置き換えにはならない。
うん、それはわかっている。
帯域が必要な分野にはLarrabeeを充ててキャッシュでそこそこ何とかなるサーバー向けCPUはのんびりいくのかなと。
Montecitoなんか未だにFSB533MT/sだもんね。144bitバスとは言え。。。
>大容量のL3やL4のキャッシュを乗せようという話
IntelのスライドによるとSandyBridgeのon-package memoryの容量は512MBとかだから従来のキャッシュとは桁が違う感じ。
これだけ容量が大きくなると制御法も従来の延長では駄目で一工夫要ると思われる。。。要するにキャッシュになるのかわからない。
まあ古いスライドなので変更された可能性もあるんだが。。。
スレ違いなのでこの辺で。
- 492 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/15(木) 22:45:35 .net]
- FSBのデータバスの転送だけ速くしても、アドレスバスの処理能力が先にネックになったら無駄なわけで。
そのあたりは難しいよね。
データはとにかく転送すりゃいいんだけど、アドレスは処理しなきゃならないから。
- 493 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/16(金) 13:59:49 .net]
- NECのＡＣＯＳ使ってるけどやっぱ、古いよな？
- 494 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/16(金) 14:01:15 .net]
- それで済むならそれでいいじゃん
- 495 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/16(金) 19:56:37 .net]
- 電気代考えると..
- 496 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/16(金) 20:01:13 .net]
- 電気代の差額ｘこれからの使用年数 が導入費用と同じ桁になるなら考えてみれば
- 497 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/16(金) 20:58:10 .net]
- いや。所有者のコストじゃなくて地球のコスト。
- 498 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/16(金) 21:11:36 .net]
- 新規導入しないほうがいい
- 499 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/01/17(土) 13:11:38 .net]
- 移行に失敗したときのリスクも考えよう。
現状のランニングコストと導入コストが一緒だから、
タダでシステムが新しくなりますよ?
なんていうセールスはアヤシイ
- 500 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/02/02(月) 12:06:16 .net]
- 「ＸＸなんていうセールスはアヤシイですよ」っていうやつがもっとアヤシイ。
|
 |
