ItaniumをUNIXで使うスレ

ItaniumをUNIXで使う� ..

287:名無しさん＠お腹いっぱい。
08/12/03 12:12:28 .net
>>281
あんた相手してるの元の人間と違うぞw

288:名無しさん＠お腹いっぱい。
08/12/03 12:14:41 .net
>>282
往生際が悪いぞ。

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

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

290:名無しさん＠お腹いっぱい。
08/12/03 13:16:23 .net
>>285
> 一部分でもバスだからダメというお前さんの主張を否定しただけだ。

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

291:名無しさん＠お腹いっぱい。
08/12/03 13:45:00 .net
>>283
アドレスリクエストがシェアードバスに流れると言いたいのか？
クロスバースイッチだって「バス」だぜ？

292:名無しさん＠お腹いっぱい。
08/12/03 13:48:09 .net
>>286
すでにXeonはクロスバーになった、という話なんだがなぁ。

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

293:名無しさん＠お腹いっぱい。
08/12/03 13:50:41 .net
270だけどなんでバスなんて一言も言ってない俺が突っ込まれなきゃならないわけ？
ItaniumもSPARCもCPU単体の能力が低すぎてどうでもいいんですけど。
何でインターコネクトの帯域にそんなにこだわるの？
OpteronだったらNUMAだしCPU性能もSPARCの数倍あって満足なわけ？

294:名無しさん＠お腹いっぱい。
08/12/03 13:50:49 .net
>>288
そういう言葉の揚げ足取りするのやめなよ。
どういう意図でバスと言ってるのか理解できるだろ。

295:名無しさん＠お腹いっぱい。
08/12/03 13:53:46 .net
>>290
CPU単体の能力が低すぎる
↓
多数のCPUをSMPで動かす
↓
インターコネクトの性能で決まる

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

296:名無しさん＠お腹いっぱい。
08/12/03 13:57:18 .net
で、だ。

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

297:名無しさん＠お腹いっぱい。
08/12/03 13:59:53 .net
>>289
> すでにXeonはクロスバーになった、という話なんだがなぁ。

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

298:名無しさん＠お腹いっぱい。
08/12/03 14:00:48 .net
>>293
それはさすがにバカ丸だしwwww Itaniumサイコー!!!!!!w

299:名無しさん＠お腹いっぱい。
08/12/03 14:05:08 .net
>>290
> OpteronだったらNUMAだしCPU性能もSPARCの数倍あって満足なわけ？

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

300:290
08/12/03 14:07:06 .net
いっとくけど俺は293じゃないからな。
ItaniumはSPARCより駄目だと思ってるし

301:名無しさん＠お腹いっぱい。
08/12/03 14:09:59 .net
盛り上がってきたなぁ...ww
今何人参加してんだろp

302:名無しさん＠お腹いっぱい。
08/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:名無しさん＠お腹いっぱい。
08/12/03 14:17:31 .net
>>296
SPARC64ねえ、それは確かにいいかもしれない。
機会があったら評価してみたい。富士通には縁が無いんだけど。
やっぱSPARC IV+より全然いいの？つかItaniumスレでする
話じゃないな

304:名無しさん＠お腹いっぱい。
08/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:名無しさん＠お腹いっぱい。
08/12/03 14:35:09 .net
p5も評価してみたいなあ。
でもアレだよね、今から評価するならCore i7ベースのXeonも
楽しみだよね。そういやXeonとItaniumでソケット共通にするって
話はどこいったの？あれが完成してればItanium用サーバーに
Xeon差したりもできたの？ってできないと意味ないか。
チップセットとかいろいろ考えたらいっそのことXeonをエンタープライズまで
対応できるようにすりゃいいじゃんって思わないでもない

306:名無しさん＠お腹いっぱい。
08/12/03 14:39:16 .net
>>294
QPIは、次の手。

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

307:名無しさん＠お腹いっぱい。
08/12/03 14:39:55 .net
とりあえず両方とも QPIになって、その次。
それまで Itanium系の開発が今の勢いで続いてれば、の話だけどw

308:名無しさん＠お腹いっぱい。
08/12/03 14:45:07 .net
>>302
Itaniumとソケット共通化で開発されていたXeonはキャンセルされて、従来通りのFSBのものが市場投入されました。
その後どうなったのかは、知らない。

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

309:名無しさん＠お腹いっぱい。
08/12/03 14:45:44 .net
>>299
> SPARC III cu 24wayとOpteron 16wayでOpteronの方が1.8倍くらい

Hypertransportは共通バスじゃない。

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

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

310:名無しさん＠お腹いっぱい。
08/12/03 14:48:50 .net
>>303
それ見ろ。今の Xeonは付け焼き刃対策してあるだけで、クロスバーへの
移行が必至なんじゃんか。そっちこそ往生際悪いぞ。

311:名無しさん＠お腹いっぱい。
08/12/03 14:52:55 .net
>>305
> だが、ソケット共通化しても、CPUだけをItaniumとXeonで交換できるとは思えない。

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

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

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

312:名無しさん＠お腹いっぱい。
08/12/03 14:58:44 .net
葬り去るっていうかIPFにいっちゃったPentium開発チームを
メインストリームのCoreに戻す策略だろうか。
しかもhp(元Alpha)の開発者というおまけつきで

確か元々Pentium開発2チーム、モバイルがイスラエル1チーム�

313:ﾅ IPFに1チームとられて、イスラエルチームがメインも作るようになったんだよね？まあうまいことAMDと競争してくれて価格性能比のいいCPUがバンバンでてくれば裏事情なんかどうでもいいけど

314:名無しさん＠お腹いっぱい。
08/12/03 15:05:31 .net
>>307
QPIはクロスバーじゃないだろ。

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

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

315:名無しさん＠お腹いっぱい。
08/12/03 15:08:45 .net
Sunの第四世代までと、第五世代のCPUボード内は、アドレスがクロスバーではなく、帯域を共有している
これは理解してもらえたかな?

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

316:名無しさん＠お腹いっぱい。
08/12/03 15:08:59 .net
Sun で言えば Mbus→UPAの段階だろ。
そんなんといっしょくたにされてたまるかw

317:名無しさん＠お腹いっぱい。
08/12/03 15:15:11 .net
>>312
いや、違うな、UPAより前の、MBus+XDBusの段階だ。

URLﾘﾝｸ(jp.sun.com)

318:名無しさん＠お腹いっぱい。
08/12/03 15:52:53 .net
SUNスレでどうぞ

319:名無しさん＠お腹いっぱい。
08/12/03 15:53:54 .net
>>312-313
おいおい。

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

320:名無しさん＠お腹いっぱい。
08/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:名無しさん＠お腹いっぱい。
08/12/03 16:01:37 .net
もひとつ、

AMDのHyperTransport → IntelのQPI

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

322:名無しさん＠お腹いっぱい。
08/12/03 16:07:01 .net
>>315
いやいや。MBusに CPU4発。これを XDBusバックプレーンに接続。
1990年代初頭の技術だな。

323:名無しさん＠お腹いっぱい。
08/12/03 19:23:54 .net
>>318
そいつはスヌープフィルタなんか持ってないんだが。

324:名無しさん＠お腹いっぱい。
08/12/03 19:26:06 .net
いまだにクロスバー信者は、キャッシュのスヌープを理解してないのか。

325:名無しさん＠お腹いっぱい。
08/12/04 09:32:17 .net
アホか。スヌープせずに MPがまともな性能で動くかwww んなもんクロスバーかどうかと
関係ないわい。
なんぼスヌープフィルタの効果が大きくても、それで「バスで OK」という
話にはならんだろうが。いつまで詭弁を弄するつもりよ?

326:名無しさん＠お腹いっぱい。
08/12/04 10:46:56 .net
興奮してる

327:名無しさん＠お腹いっぱい。
08/12/04 11:02:50 .net
>>321
スヌープの意味、わかってないね?
スヌープしなかったらキャッシュのコヒーレンシを実現できない。

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

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

328:名無しさん＠お腹いっぱい。
08/12/04 11:36:55 .net
もうループに入りました。

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

329:名無しさん＠お腹いっぱい。
08/12/04 11:38:52 .net
>>323
そんでもも一回だけ。

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

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

330:名無しさん＠お腹いっぱい。
08/12/04 11:44:47 .net
クロスバーと１回発言すると、どこからかお金が貰えるの？
なら俺も書こうかな。

331:名無しさん＠お腹いっぱい。
08/12/04 12:12:35 .net
「スヌープフィルター」は、金貰えるのか?

332:名無しさん＠お腹いっぱい。
08/12/04 12:33:17 .net
>>324
なんかね、>>321はスヌープフィルタのつもりでスヌープと言ってるっぽいのよ。

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

333:名無しさん＠お腹いっぱい。
08/12/06 11:05:00 .net
328でFAだな

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

334:名無しさん＠お腹いっぱい。
08/12/08 12:04:28 .net
Sun信者が無知だってことが明らかになりました

335:名無しさん＠お腹いっぱい。
08/12/17 03:08:26 .net
このスレ久しぶりに来たけどこの話題何回繰り返すんだろうなｗ

336:名無しさん＠お腹いっぱい。
08/12/17 05:01:14 .net
>>331
それは構って欲しいですっていう意味か?

337:名無しさん＠お腹いっぱい。
08/12/17 09:41:45 .net
「そっとしといてほしい」みたいだぜ。たとえ話題皆無でもw

338:名無しさん＠お腹いっぱい。
08/12/17 12:44:29 .net
Sunの糞信者に荒らされるよりは、何も話題がないほうがマシ。

339:名無しさん＠お腹いっぱい。
08/12/17 13:37:33 .net
なんか話題ないの?

340:名無しさん＠お腹いっぱい。
08/12/18 00:55:53 .net
話題無いって言う話題ぐらいしかないねぇ。。。

341:名無しさん＠お腹いっぱい。
08/12/18 01:06:54 .net
Itaniumを仕事で使っているような人は、いまどき2chなんかやらんだろ。

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

342:名無しさん＠お腹いっぱい。
08/12/18 01:17:34 .net
4Q08に発表するという話だったのにまた遅延かという話題ならある

343:名無しさん＠お腹いっぱい。
08/12/18 13:09:47 .net
夢がふくらまないな...w

344:名無しさん＠お腹いっぱい。
08/12/18 13:20:17 .net
>>337
「昔」には 2chなんて「ない」と思うがww

345:名無しさん＠お腹いっぱい。
08/12/18 17:06:44 .net
2chの昔な。

346:名無しさん＠お腹いっぱい。
08/12/18 18:24:58 .net
Itaniumってコンパイラがもっと進化すれば爆発的に早くなるはずじゃなかったの？
もしかして「早すぎたんだ・・・」っていうやつなの？

347:名無しさん＠お腹いっぱい。
08/12/18 19:00:16 .net
x86が爆発的に性能向上してしまったので霞んでしまっただけです。

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

348:名無しさん＠お腹いっぱい。
08/12/18 19:06:18 .net
i860の Wikipediaにはこう書いてある。

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

EPICは、どうかなww

349:名無しさん＠お腹いっぱい。
08/12/18 19:33:37 .net
>>344
おまえ、i860のアーキテクチャを理解してないだろ。

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

350:名無しさん＠お腹いっぱい。
08/12/18 21:41:38 .net
>>342
最近ではHP-UX 11iV3で結構速くなったよ。
ただCPUがMontecitoのままじゃねえ。。。
コンパイラが神の様に賢くても理論演算性能を超えることは決してないからさ。

351:名無しさん＠お腹いっぱい。
08/12/18 22:46:44 .net
HPはさ、PA-RISCもベンチマークだけは速いけど実際は・・・っていうシロモノだったから、
IA-64になってもショックが小さいと思うんだわ。

352:名無しさん＠お腹いっぱい。
08/12/18 23:33:40 .net
Tukwila最強！

353:名無しさん＠お腹いっぱい。
08/12/18 23:44:30 .net
SPARCはベンチマークは駄目だけど、実際は・・・だけどな。。

354:名無しさん＠お腹いっぱい。
08/12/18 23:52:03 .net
SPARC最弱！

355:名無しさん＠お腹いっぱい。
08/12/19 00:03:15 .net
Sun信者ウザイよ。Sunの話はSunスレでやれよ。

356:名無しさん＠お腹いっぱい。
08/12/19 00:23:02 .net
そうだ、そうだ！

357:名無しさん＠お腹いっぱい。
08/12/19 02:14:45 .net
TukwilaもRockに対抗して250Wバージョンを出すべき！

358:名無しさん＠お腹いっぱい。
08/12/19 04:22:52 .net
URLﾘﾝｸ(www.anandtech.com)
上の記事のせいで海外の掲示板に「Tukwilaも爆速なんじゃね?」とか言い出す厨房が氾濫しているから困る。

359:名無しさん＠お腹いっぱい。
08/12/19 11:08:15 .net
>351
あわれだなぁ.. ここは Sunのとこから派生してできたんだって何度言えば..
Itaネタで埋まるくらい書いたらどうよ?

360:名無しさん＠お腹いっぱい。
08/12/19 11:11:15 .net
>>98-102

361:名無しさん＠お腹いっぱい。
08/12/19 11:38:07 .net
>>344
i860は、Itaniumと比べると、
意図と結果がはっきりしたすがすがしいプロジェクトだった。
CPUは消えたが、多くの豊かな結果が残った。

362:名無しさん＠お腹いっぱい。
08/12/19 12:34:49 .net
>>355
お前がスレに参戦する前からItaniumスレあったと思ったが。

>>357
翻弄された人たちは多かったけどね。

363:名無しさん＠お腹いっぱい。
08/12/19 14:16:08 .net
> お前がスレに参戦する前からItaniumスレあったと思ったが。
Niagara発表されたとき意味全くわからなかったアホを隔離するための場所なんだが
ここはwwww

364:名無しさん＠お腹いっぱい。
08/12/19 14:20:45 .net
>>345,357
i860じゃなくても、iAPX432でもいいんだけどwwww

| 後の研究では、もっとも大きな問題はコンパイラに有ったと指摘されている。
| すなわち、コストの低い..

365:名無しさん＠お腹いっぱい。
08/12/19 14:35:10 .net
>>345
意味不明だな。パイプラインをうまく満たせない、すなわち性能出ない、て主旨だぞ。
他に前提としてなんか理解してないといかんのかw? ワケワカランp

366:名無しさん＠お腹いっぱい。
08/12/19 14:37:38 .net
結局SPARC馬鹿がいないとスレが盛り上がらないのか

367:名無しさん＠お腹いっぱい。
08/12/19 17:04:17 .net
>>359
少なくとも前スレの冒頭から見てるけど、Sun信者が乗っ取った形だな。

>>361
そりゃ、i860のパイプラインモードがどんなものか理解していなければ、意味不明だろうな。
そういう点で、日本語のwikipediaのi860の説明はダメだな。英語版にはちゃんと説明があったと思う。

368:名無しさん＠お腹いっぱい。
08/12/19 17:34:34 .net
SPARCとItaniumでどっちが先に死ぬか競争だな
x86に統合されて先にItaが死にそうな気がするけど

369:名無しさん＠お腹いっぱい。
08/12/19 17:36:04 .net
どっちもなかなか死なないと思うよ

370:名無しさん＠お腹いっぱい。
08/12/19 22:33:43 .net
敵どころか己が持ちあげている物すら知らなかったSun信者が、Sunスレで勝利宣言しててﾜﾛﾀ

371:名無しさん＠お腹いっぱい。
08/12/22 11:11:00 .net
誰か >>366 解説してやってくれ。それか、医者へ連れてってやってくれ。

372:名無しさん＠お腹いっぱい。
08/12/22 13:53:15 .net
>>367
人に頼るなよ。

373:名無しさん＠お腹いっぱい。
08/12/29 11:09:30 .net
>>367
しらないなら
いばるなよ
だめ
こんさる

374:名無しさん＠お腹いっぱい。
08/12/31 10:49:27 .net
知ったかインチキが偉そうに

375:名無しさん＠お腹いっぱい。
09/01/01 11:42:53 .net
Itaサーバの中古、どっかに安いのはないかな

376:名無しさん＠お腹いっぱい。
09/01/02 09:26:25 .net
506 名前：MACオタ＞502 さん[sage] 投稿日：2009/01/01(木) 23:29:46 ID:os1mREWn
>>502
　　--------------
　　Tukwilaはどうなったんだ？もう2009年ですよｗ
　　--------------
更に遅れて今年の第2四半期になった模様す。
URLﾘﾝｸ(server.it168.com)
　　==============
　　??英特?将在2009年的第二季度将Tukwila正式推向市?。
　　==============

508 名前：MACオタ＞507 さん[sage] 投稿日：2009/01/01(木) 23:44:46 ID:os1mREWn
>>507
私も英訳して読んでいるす。
Intelの営業のヒトの話なので、特にネガティブなことわ書いてないす。
URLﾘﾝｸ(translate.google.com)
　　----------------------
　　Gu who also disclosed that next-generation Itanium platform Tukwila testing machines
　　have been sent to OEM manufacturers and important ISV, the partners are currently on
　　the database, ERP, high-performance computing applications such as authentication and
　　running the program, Intel is expected to be the second quarter of 2009 will be formally
　　Tukwila market.
　　----------------------

377:名無しさん＠お腹いっぱい。
09/01/02 13:18:49 .net
CPUだけ出してもしょうがないので、Tukwila搭載マシンの開発と両輪で進んでいるのだろう。

378:名無しさん＠お腹いっぱい。
09/01/02 13:27:02 .net
Tukwilaってまだやっていたのか

379:名無しさん＠お腹いっぱい。
09/01/04 01:06:02 .net
>>373
つまり、以前のように本気でチップセット用意してくれる企業が減った（無くなった?）
ということか。

380:名無しさん＠お腹いっぱい。
09/01/04 01:17:49 .net
当たり前だがHPはItaniumが死ぬまで真剣にやる。脱落？したのはIBM？ユニシス？これは結構古い話だよな？
ああ、富士通か？PRIMEQUESTの新モデル出ないの？やるとおもってたが。
ま、Tukwila以降では4コアより純正チップセットの復活が大きいな。
アンチIBMの旗の下集まったISAがようやく本格的に動き出すと思う。
Dellみてればわかるが純正はとにかく安いからな。

381:名無しさん＠お腹いっぱい。
09/01/04 01:25:27 .net
連投だがチップセットに合わせて投入するとしたらHPのsx/zxシリーズかIntel純正のBoxboroだよな。
富士通に歩調を合わせるとは思えんし。
でBoxboroのスケジュールはXeonMP(Nehalem-EX, Beckton)の2009年半ばだからこっちは時期的には合う。
HPだけ半年早くTukwilaのサーバー売れるようにしたら不満たらたらだろうしな。

382:名無しさん＠お腹いっぱい。
09/01/04 01:29:26 .net
ユニシスはNECと組んだ時点ではまだやる(NECに作ってもらう)って言ってなかったっけ？
最近、NECとの提携の成果であるXeonサーバ発表した時にはもうやらねって言ってたが

383:名無しさん＠お腹いっぱい。
09/01/04 01:43:51 .net
テープアウトしたとかファーストシリコンとかいって
2008年に出す出す詐欺
結構な偉業だと思う

てかもう製品出来てるだろ
古いプロセスに古い設計
減らされたとは言え数百人規模の開発チーム
出来てないわけがない

もうねHPのMCサーバー部門ごと買い取ればよかったのに
プロセッサのデザインチームだけと言わずにさ
で、みんなでIntel OEM
健全でしょ

Sunに置ける富士通的ポジションだよ
やってやれないことはない

まーこれは冗談だけど
Itaniumはねー絶対健全化できる
POWERやSPARCも一時期は駄目だったけど復調した
必要なのは社内でリーダーシップとってくれる人
予算でも人的リソースでもない

384:名無しさん＠お腹いっぱい。
09/01/04 01:55:55 .net
そうなんだ

385:名無しさん＠お腹いっぱい。
09/01/04 02:45:44 .net
Itaniumが担う領域って水平分業型だと信頼性が確保しきれないところだからね
HPのIntegrity部門ごと買った方が良かったってのは、あながち冗談とも言えないかも
でも、世の中のほとんどの業務は実はXeonMPの信頼性で十分なはずなんだよね
誰も人柱になりたくないから、メインフレームとかMCサーバ買い続けてるってだけで

Intelの本音としては、もうItaniumは辞めたいんじゃないかなあ
下手に健全化なんかしたら辞める口実が無くなっちゃうじゃないの

386:名無しさん＠お腹いっぱい。
09/01/04 14:12:06 .net
>>375
そうじゃない。

サーバのメーカーがチップセットを開発して搭載機の受注を開始できる体制になってからでないと、
CPUの出荷開始を発表できないの。

387:名無しさん＠お腹いっぱい。
09/01/04 14:17:33 .net
サーバのメーカーが
チップセットを開発して
搭載機を開発して、
ソフトウェアを開発して、
テストが済んで、
受注を開始できる体制
だな。

初代Itaniumは、そういうのが揃っていなくて、CPUが塩漬け状態だった。
かなりのステッピングがあるので、CPU自体のエラッタも沢山あったのだろうが。

388:名無しさん＠お腹いっぱい。
09/01/04 16:50:26 .net
だんだん馬脚が現れてきたなww 苦しさ満点。まあ、がんばってくれやw

389:名無しさん＠お腹いっぱい。
09/01/04 17:12:48 .net
↑何を言いたいのかさっぱりわからない書き込みだな

390:名無しさん＠お腹いっぱい。
09/01/04 17:34:52 .net
まぁ、いつものことだ。気にするな

391:名無しさん＠お腹いっぱい。
09/01/05 09:45:32 .net
やっぱメーカー関係者だったんだな、てことさ。
他に道がない、ということを解らんでもないが、後世振り返ってそこに価値を
見い出せるかということも考えた方がいいと思うぞ。

392:名無しさん＠お腹いっぱい。
09/01/05 12:21:52 .net
Sun信者さん、こんなところで荒らしてないで。

393:名無しさん＠お腹いっぱい。
09/01/05 13:51:11 .net
>>381
x86が多少延命した、と言っても別の将来性を見い出した訳でもなんでもなくて、
「先がない」のは Ita発表した頃に Intel自身が言ってた通り、何も変わってない。
で、問題はその代替えとして Itaがダメだってことで、これも何も変わってなくて、
もう確定事項。後は、プロセスの改良と x86のチューニングしか残ってない。
ARMもよー扱わんかった。

やっぱ、i960改良するのが正しいんじゃね?w バークレーRISCだしさwwww

394:名無しさん＠お腹いっぱい。
09/01/05 14:38:37 .net
>>389
どう見てもSun信者です。お引き取りください。

395:名無しさん＠お腹いっぱい。
09/01/05 15:02:13 .net
>>389
おまえ未だRISCが高性能だと思ってんのか。

396:名無しさん＠お腹いっぱい。
09/01/05 15:08:27 .net
>>379
> Itaniumはねー絶対健全化できる

> 必要なのは社内でリーダーシップとってくれる人

2つ問題がある。

一、Intelにその気がない。
二、たとえ健全化しても単に「健全」というだけでは
わざわざ新規 ISAに移行する動機付けにならない。

200x年代初頭の Itaが今のポジションだったとしても、厳しいねぇ。
なんせ x86を「置き換える」はず、だったんだから。目標到達にはほど遠い。

397:名無しさん＠お腹いっぱい。
09/01/05 15:09:13 .net
いまどきプロセッサの性能を決めるのは、メインメモリへのアクセスのレイテンシと効率。

命令セットのうち、レジスタ間や即値との演算の命令なんて、どうでもいい。
肝心なのは、メモリアクセスのための命令。

398:名無しさん＠お腹いっぱい。
09/01/05 15:12:27 .net
>>392
最終的にはx86は他の命令セットに移行する可能性がある。
それがIA-64とは限らないが。

いままで何度も、
バイナリトランスレータによる事前変換あるいはや実行時変換が試みられてきた

これからも、そのような試みは続けられる

そして、いつか、その試みは成功するだろう。

399:名無しさん＠お腹いっぱい。
09/01/05 15:13:23 .net
あら人気スレ

400:名無しさん＠お腹いっぱい。
09/01/05 15:13:26 .net
>>391
このまま EPICを置き換える VLIWな ABIが出てこなければ、
長期にわたる後方互換性の必要な ISAとして VLIWはダメ、ということになるだろな。
ちなみに、Intelみたいなどこにもマネのできんリソースをつぎこむことなく
CISCアーキを維持できてる会社どっかあんのか? 全部 RISCだろ?

401:名無しさん＠お腹いっぱい。
09/01/05 15:13:33 .net
ていうかSunはx86バイナリをSPARC上で実行する試み、やめちゃったの?
昔はやってたよね。

NiagaraとかRockがそんなに素晴らしい、スケールするのであれば、
x86バイナリをSPARC上で実行するサーバを出せば売れるだろう。

402:名無しさん＠お腹いっぱい。
09/01/05 15:14:11 .net
RISCは高性能だね
それ以外のは生き残れなかった

403:名無しさん＠お腹いっぱい。
09/01/05 15:16:47 .net
>>393
まるで間違い。それなら組込み機器も大規模 SMPも全部 x86になってるはず。
ところが、x86は実際にはパチョコン以外ではまるで使えない、用途限定石。

404:名無しさん＠お腹いっぱい。
09/01/05 15:17:38 .net
>>396
VLIWって互換性を捨ててるアーキテクチャでしょ。

自分でmakeすりゃいいじゃんっていうオープンソース文化の人たちや、
互換性のために生の命令セットは見せないというアプローチ、
あるいは組込みなんだから、互換性とか関係ないねって分野でないと、
VLIWは難しい。

そのVLIWの問題点を解決した、VLIW風だがVLIWではないEPICは、
いまのところ長期にわたるバイナリ互換を確保できていると思う。

試していないが、現行のバイナリは初代Itaniumでも実行できるんじゃね?
バンドルの組み合わせが増えてる分は例外でエミュレーションで劇遅かもしれんが。

405:名無しさん＠お腹いっぱい。
09/01/05 15:21:08 .net
>>396
Centaur Technologyを忘れないでください。

>>399
あなたは偏見と罵倒前提で曇った目で他人の書き込みを読むから、意図が理解できないのですよ。
x86のメモリアクセスのための命令がネックで大規模SMPの効率が悪いって示唆してるんですがね。

ちなみに組込みではx86は目立たないけど使われ続けてます。
私の目の前に有るDELLの液晶モニタはOSDコントローラがx86ですよ。

406:名無しさん＠お腹いっぱい。
09/01/05 15:27:20 .net
そのケンタウロスは生きているのか死んでいるのか

407:名無しさん＠お腹いっぱい。
09/01/05 15:35

408::29 .net

409:名無しさん＠お腹いっぱい。
09/01/05 15:42:57 .net
そりゃ安いか速いか少なくともどっちかは満たさないとねえ

410:名無しさん＠お腹いっぱい。
09/01/05 15:55:38 .net
え? SunのNiagara2はXeonとは比べ物にならないほどコストパフォーマンスがいいんでしょ?

411:名無しさん＠お腹いっぱい。
09/01/05 15:57:21 .net
x86は命令セットがスケールしない仕様なので、たとえSPARCの命令セットに変換してもスケールしないだろ。

412:名無しさん＠お腹いっぱい。
09/01/05 16:09:32 .net
>>405
そういう意味ではない。あんたの思いつく程度のことは RISC WS陣営がとっくに
やったし、Itaもそれ以上のことはしていない。
当初 Intelが言ってた、「x86を置き換える」ことができなければ、
あまり存在意義があるとは思えない。
金持ってるから、今の位置付けのまま維持することは可能だろうけど。
株主につつかれなきゃ。

413:名無しさん＠お腹いっぱい。
09/01/05 16:19:09 .net
>>401,406
なるほど! じゃ、その効率の悪い「メモリアクセス命令」を禁止したサブセットを
定義して、コンパイラーにスイッチ付ければすべて解決じゃん!!
すげーな、スケールしまくりの新 x86アーキ! 期待してるよw

:
もちろん、RISCに似ちゃったり. ...しないよね?wwww

414:名無しさん＠お腹いっぱい。
09/01/05 16:28:24 .net
>>407
x86を置き換えれなかったからといって、存在意義がないとは言えん。

x86では届かない部分をカバーするという意味はあるし、
その領域でItaniumで経験したことや実績は、将来にx86がカバーするようになるための基礎になりえる。

>>408
別にコンパイルするなら、x86である必要ないじゃん。
最初からSPARCをターゲットにコンパイルすりゃいい。

Sun信者はいつも、意図的に間違った方向に話を持っていくね。

415:名無しさん＠お腹いっぱい。
09/01/05 16:35:58 .net
>>409
> x86を置き換えれなかったからといって、存在意義がないとは言えん。

もちろん、「もう優秀な RISC ISAがたくさんあるんだから、」その上には
必要ない、という意味。

> x86では届かない部分をカバーするという意味はあるし、
> その領域でItaniumで経験したことや実績は、将来にx86がカバーするようになるための基礎になりえる。

それも同じ。わざわざ Itaでやらんでもよい。もうたくさんある。

> Sun信者はいつも、意図的に間違った方向に話を持っていくね。

はっはっはっはっ。君、おもしろいね?w

416:名無しさん＠お腹いっぱい。
09/01/05 16:47:47 .net
>>410
Intelにとっては、というのは明記しなくても、読み取れるだろうが・・・

417:名無しさん＠お腹いっぱい。
09/01/05 16:50:19 .net
アホか。その前のを読み取ってないのはオマエじゃw ほんとにオモロイなk

418:名無しさん＠お腹いっぱい。
09/01/05 16:53:17 .net
はい>>412が誰かを煽ることを目的にスレに粘着していることを白状しました。以後スルー推奨。

419:名無しさん＠お腹いっぱい。
09/01/05 16:58:21 .net
「誰かを煽る」んじゃなくて、単にアホにアホと言ってるだけなんだが。
妄想ハゲしいねww

420:名無しさん＠お腹いっぱい。
09/01/05 16:59:09 .net
なんつーか、この苦し紛れさ加減はwwww

421:名無しさん＠お腹いっぱい。
09/01/05 17:09:36 .net
消費電力が少なくてやっすいのを一台なんとか

422:名無しさん＠お腹いっぱい。
09/01/05 17:12:10 .net
>>414-415
連投しないと気がすまない病?

423:名無しさん＠お腹いっぱい。
09/01/05 17:43:01 .net
>>417
偽・スルーみんなにスルーを呼びかける。実はスルーできてない。
失敗スルー我慢できずにレスしてしまう。後から「暇だから遊んでやった」などと負け惜しみ。
疎開スルー本スレではスルーできたが、他スレでその話題を出してしまう。見つかると滑稽。

3つはあてはまるなww

ここからスルーできるかな～?www おかしーw

424:名無しさん＠お腹いっぱい。
09/01/05 17:48:51 .net
うれしそうですね

425:名無しさん＠お腹いっぱい。
09/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:名無しさん＠お腹いっぱい。
09/01/05 18:20:13 .net
SPARC liteが組込みに使われていた・・・ってのも過去の話だよね。

そのうちAtom採用のデジカメとか、個人向けプリンタ・スキャナ複合機が出てくるだろうね。
そんな無駄だろ? って思うかもしれないが、開発のしやすさがまるで違うんだわ。

427:名無しさん＠お腹いっぱい。
09/01/05 22:47:24 .net
おまえら仕事しろ

428:名無しさん＠お腹いっぱい。
09/01/06 09:53:30 .net
>>421
> 開発のしやすさがまるで違うんだわ。

そんなバカなww 「既存の xxがあるから」、だろ? そりゃ他知らんだけ。

429:名無しさん＠お腹いっぱい。
09/01/06 10:17:57 .net
>>423
じゃぁ何でx86が組込みに使われてると思ってんだ?

430:名無しさん＠お腹いっぱい。
09/01/06 13:31:40 .net
「使われてる」なんて言うほど使われてないよ。80186の類はいっぱい使われてるけどな。

431:名無しさん＠お腹いっぱい。
09/01/06 13:43:25 .net
SPARCとどっちが多い?

432:名無しさん＠お腹いっぱい。
09/01/06 13:44:16 .net
東芝のHD DVDレコーダーは、x86だったな。
80186とかそんな非力なのではなくて。

433:名無しさん＠お腹いっぱい。
09/01/06 13:44:46 .net
だから失敗したのか

434:名無しさん＠お腹いっぱい。
09/01/06 13:46:44 .net
そうだな。SPARCだったら大成功だったところだ。

435:名無しさん＠お腹いっぱい。
09/01/06 13:50:17 .net
HD DVDプレーヤーにMobile Pentium4 2.54GHzが積まれててﾜﾛﾀ。

436:名無しさん＠お腹いっぱい。
09/01/06 13:59:37 .net
そういうのはパソコンまるごとから削ったタイプのやつだな。
組込み全体から見たら僅かに過ぎんが.. もうひとくくりで語るべきじゃないだろな。
今後増えるだろし。

437:名無しさん＠お腹いっぱい。
09/01/06 14:34:37 .net
Itaniumの話をしてください

438:名無しさん＠お腹いっぱい。
09/01/06 16:19:03 .net
>>431
組込み全体の話なんかナンセンスだよ。
組込みのうちSPARCが使われている領域の話に限定しなよ。

NASなんかは、「パソコンまるごとから削ったタイプ」そのものだよ。

439:名無しさん＠お腹いっぱい。
09/01/06 17:21:52 .net
「x86に将来性なし」ってのは別にオレが言ったことでもなく、
ここの誰が言ったわけでもなく、Intelが言ったことなんだが。
なんでこう諦めが悪いかなww
んでもって、そんな x86の諦め悪いやつがなんでここにいるんだ?
amd64のデキがよかった、Meromのデキがよかった、Atomのデキがよかった、
そんなことが「x86の将来性」ないのを覆した、とか思ってるわけ?
先延ばししただけでしょ、どうヒイキ目に見ても。

440:名無しさん＠お腹いっぱい。
09/01/06 17:40:40 .net
Intelが間違わないという保証があるわけじゃないな

441:名無しさん＠お腹いっぱい。
09/01/06 17:52:44 .net
>>434
お前、なんで必死なんだ?

442:名無しさん＠お腹いっぱい。
09/01/06 18:19:52 .net
命令セットがどうこうってのは20年ほど前の議論だよな
結果から言えば当時の人たちはトレンドを読み外したということでFA

443:名無しさん＠お腹いっぱい。
09/01/06 18:43:40 .net
何の話してんの?

444:名無しさん＠お腹いっぱい。
09/01/06 18:46:11 .net
分からないなら黙ってればいいのに

445:名無しさん＠お腹いっぱい。
09/01/06 18:47:11 .net
なんでそんなに必死なの? ..w

446:432
09/01/06 19:22:22 .net
Itaniumのことだけ書いてください

447:名無しさん＠お腹いっぱい。
09/01/06 19:30:57 .net
Itaniumの話か。

AMDにIA-64を採用するように働きかけなかったIntel
IA-64を採用しようとしなかったAMD
この2社が、世界のパソコンの将来に大きな負債を残した

448:名無しさん＠お腹いっぱい。
09/01/06 19:49:43 .net
そうだな。その後 IA-64がコケたとしても、今とは別の展開があっただろう。
あんまり期待できんがw

「両者それぞれ am29k, i960を復活、バークレーRISC乱立の混迷へ」...w

449:名無しさん＠お腹いっぱい。
09/01/06 20:01:52 .net
IA-64の命令セットと、プロセッサの実装を、分けて考えないと。

技術力のないインテルの実装だからItaniumがアレなんであって、
技術力の優れたAMDが実装すればIA-64でありながら素晴らしい
プロセッサが出来あがっていたかもしれないぞ。

IA-64の、とりあえず実行して結果を捨てるのは消費電力的に無駄が多いが、
現状のx86の、複雑なデコードや、同時に実行できる命令を探したり・・・etcの消費電力も大きい。
IA-64の場合、実行ユニットを減らすことも可能で、SPARCのレジスタ数によるスケールよりは、よっぽどスケールする。

初代はともかくMckinley以降はさほど悪くない。
もしインテルがx86と同じだけのリソースを割いて最先端のプロセスで生産すれば、違ったことになってただろう
とはいえ、x86と同じだけのリソースを割くなんて、ありえない仮定だが。

450:名無しさん＠お腹いっぱい。
09/01/06 20:27:44 .net
Itaniumの一番ダメな点 = レジスタウィンドウもどきを実装していること。

451:名無しさん＠お腹いっぱい。
09/01/06 20:48:30 .net
Itaniumの一番ダメな点 = EPICじゃないの？

452:名無しさん＠お腹いっぱい。
09/01/06 20:49:26 .net
2001年頃にAMDが潰れてればx86からIA-64への強制的な移行が推進されたのかもな
今は”やっぱり命令セットは拡張できる方がイイヨネ！”って時代なのでありえない話

453:名無しさん＠お腹いっぱい。
09/01/06 21:09:40 .net
Intelが用意していた(AMD64ではない)x86の64ビット拡張は、IA-64とは違うものだったらしいですよ。

454:名無しさん＠お腹いっぱい。
09/01/06 21:10:51 .net
なんだかやる気のないやつね

455:名無しさん＠お腹いっぱい。
09/01/06 21:35:18 .net
どうせAMDにペースを握られたくないという理由だけで策定した間に合わせのものだろう
あるいはx86_64よりIA-64のほうがいいよねって流れに誘導したかったんじゃないかと

456:名無しさん＠お腹いっぱい。
09/01/06 21:40:39 .net
まあそれでもちゃんとキャッチアップしてCore2DuoとかCore i7出したんだから
結果的にはよかったんじゃないかな。

457:名無しさん＠お腹いっぱい。
09/01/06 21:50:34 .net
それにしたってAMD64は、ヤッツケ仕事すぎる。

命令セットを大きく拡張あるいは変更できるチャンスというのは、
16→32ビット、32→64ビットの次は、64→128ビット・・・はないだろう。
だから、16→32ビットの時よりも遥かに将来を見通して策定すべき。
にもかかわらず、目先のことだけ考えた安易な拡張。これはひどい。

レジスタをすべて等価にするのではなく、2段階のコストにした点は評価できる。
良く使うレジスタは速く、あまり使わないレジスタは遅くというのは、
RISCが旗印にしていた定量的アプローチ、だものね。

458:名無しさん＠お腹いっぱい。
09/01/06 21:54:06 .net
まあインテルさんがIA64とかにかまけてないでまじめに
x86の拡張をかんがえてればよかったんじゃないのかなー
まあ状況的に無理だけど
だから次善の策としてamd64はよかったんじゃないかな

459:名無しさん＠お腹いっぱい。
09/01/06 21:55:59 .net
>>451
なんかIntelやばいんじゃね？と思ったら常勝の帝国軍へ戻っていた
な、なにを言ってるのかわからねーとおもうが(ry

460:名無しさん＠お腹いっぱい。
09/01/06 22:03:21 .net
x64だっけ?

アセンブラのニーモニックのレベルではx64のそれでいいとしても、
せめてオペコードなどの割り当ては真っ新からやり直すべきだった。

32ビットと64ビットでデコーダを共用できなくなるが、
だがしかし、ここでキレイに整理しておけば、後々かなり楽になる。

461:名無しさん＠お腹いっぱい。
09/01/07 07:04:56 .net
オペコードが人間が綺麗と感じるように割り当てられてることにどんな意味があるの？

462:名無しさん＠お腹いっぱい。
09/01/07 10:43:16 .net
> オペコードが人間が綺麗と感じるように

はいはい、意図的に誤解して架空の話を叩いて喜んでないで仕事しようね。

463:名無しさん＠お腹いっぱい。
09/01/07 10:43:26 .net
デコーダがシンプルになる...いまどきどうでもよいが。
将来の拡張の余地が広がる。これは大きい。

464:名無しさん＠お腹いっぱい。
09/01/07 10:45:34 .net
AVXでおk

465:名無しさん＠お腹いっぱい。
09/01/07 10:54:44 .net
AVX?

あれ長いよ。

たった1バイトしか短くならない・・・1バイトでも短くなることは重要ではあるし、
その次の拡張で長くならないことも重要なのだが、グダグダっしょ。

466:名無しさん＠お腹いっぱい。
09/01/08 15:11:25 .net
ほれ見ろ。オレがネタ投下してやんないとなんも出んがなw

467:名無しさん＠お腹いっぱい。
09/01/08 15:13:49 .net
安くて消費電力の少ないIta2マシンどっかに落ちてないかな
中古でいいよ

468:名無しさん＠お腹いっぱい。
09/01/10 00:42:48 .net
そんな製品がないんだから中古なんてなおさらあるわけないw
複雑化の原因はコンパイラにまかせてコアは単純化されてるはずだから
キャッシュ減らしたら電力食わないんだろ、きっと。そうに違いないwww

469:名無しさん＠お腹いっぱい。
09/01/10 20:06:22 .net
キチガイはスルーで

470:名無しさん＠お腹いっぱい。
09/01/10 21:05:06 .net
>>433
NASとCPUと言えば、AuspexがSPARCでやっていたのを、
廉価NAS構成に対向しようとx86に移行しようとして失敗沈没してﾜﾛﾀ
コントローラはSolaris for x86で問題なかったけど、
独自ファームのエンジンがどうにもならなかったみたい。
やっぱCPU移行は慎重にやらないとね。
本当にメリットがあるのかどうか。どのCPUでも。

>>452
AMDはそういう路線だからしかたないんじゃ？
コストかけて研究部門維持するわけにもいかないし。

471:名無しさん＠お腹いっぱい。
09/01/10 21:23:58 .net
AMDを責めてもしかたないわな。
水先案内人としての責任は、牽引する立場のIntelにある

472:名無しさん＠お腹いっぱい。
09/01/10 21:28:21 .net
市場を完全に制圧してからやるべきだったね
その辺Microsoftは賢い

473:名無しさん＠お腹いっぱい。
09/01/10 21:33:14 .net
AMDはIntelの失敗を修正する役割があると

474:名無しさん＠お腹いっぱい。
09/01/10 21:36:05 .net
>>452
Intelの最適化まぬあるによると増えたレジスタは使うなというｗ

475:名無しさん＠お腹いっぱい。
09/01/10 21:38:25 .net
あはははは

476:名無しさん＠お腹いっぱい。
09/01/10 22:12:26 .net
>>467
そのほうが消費者の利益になったとしても、独占ってだけで叩かれるぞ。
個人的にはAMDのIA-64実装を見てみたかった。

>>468
Intelを牽制する役割、だろうな。

>>469
IntelのCPUだと増えたレジスタを使った場合に、ガクンと遅くなるんだよな。
そりゃ、使うなと書いて当然だ。

こういう新しい命令セットってのは、互換性が重要なのよ。
最初にインプリしたCPUでは、速く実行できる必要はなくて、とにかく、正常に実行できることが重要。
その命令セットを実行できるCPUが市場に十分に出まわった時点で、本格的にソフトが使いはじめる。
この時点で、その命令セットを高速に実行できるCPUを市場に投入すればいいの。

まったく実行できない
と
遅いけど実行できる
というのでは、まるでインパクトが違う。

うまく移行するためには、早くから種まきしておかないと。

477:名無しさん＠お腹いっぱい。
09/01/10 22:22:44 .net
命令長伸ばしてレジスタ拡張なんて最近流行の電力効率に反する実装だからだよ
AVXの目的もそういうことだ

478:名無しさん＠お腹いっぱい。
09/01/10 22:32:30 .net
やっぱり、64ビット拡張するときに、OPコードを大胆に整理すべきだったんだよ。

モードによって違うのはデコーダのコストが増えるが、
しかし、
命令長が長いのに比べたらマシだと思うんだわ。

もったいないよ。使わない命令が短くて、使う命令が長いのは。

479:名無しさん＠お腹いっぱい。
09/01/14 01:57:08 .net
なんか自作板にTukwilaはDDR3サポートに変更になったとか書き込みがあった。

480:名無しさん＠お腹いっぱい。
09/01/14 12:11:19 .net
そうなればそうなるわな

481:名無しさん＠お腹いっぱい。
09/01/14 12:58:33 .net
以前からDDR3系のFB-DIMM2も対応予定に入ってなかったっけ？
それともFB-DIMM1のサポート無くしたという意味かな。

482:名無しさん＠お腹いっぱい。
09/01/14 16:18:08 .net
え?

FBってのは、DRAMチップのI/Fが変ってもOKっていう柔軟性も兼ね備えているんじゃないの?

483:名無しさん＠お腹いっぱい。
09/01/14 16:39:30 .net
2007年の時点で、
DDR3を使ったFB-DIMMの提供予定はない
っていう話だった。

484:名無しさん＠お腹いっぱい。
09/01/14 16:40:48 .net
FB-DIMMやめて直にDDR3のメモリコントローラを積むって話では?

485:474
09/01/14 22:32:03 .net
>>478
そのあとFB-DIMMのバッファチップをマザーボードに置くとかいう話が出てきた。
そうするとスロットに挿すメモリはDDR3だけどMCHのインターフェースはFB-DIMMになる。

>>479
うん、そんな感じだった。

次ページ