[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 2ch.scのread.cgiへ]
Update time : 09/08 20:46 / Filesize : 182 KB / Number-of Response : 815
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

ItaniumをUNIXで使うスレ



1 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/07/14(月) 19:44:39 .net]
実際に使ってみた人、どうよ?

前スレ
ItaniumでUNIX!
pc11.2ch.net/test/read.cgi/unix/1140329582/


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



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

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

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

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

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

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

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

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

384 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/01/04(日) 01:55:55 .net]
そうなんだ

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

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

386 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/01/04(日) 14:12:06 .net]
>>375
そうじゃない。

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

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

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



388 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/01/04(日) 16:50:26 .net]
だんだん馬脚が現れてきたなww 苦しさ満点。まあ、がんばってくれやw

389 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/01/04(日) 17:12:48 .net]
↑何を言いたいのかさっぱりわからない書き込みだな

390 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/01/04(日) 17:34:52 .net]
まぁ、いつものことだ。気にするな

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

392 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/01/05(月) 12:21:52 .net]
Sun信者さん、こんなところで荒らしてないで。

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

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

394 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/01/05(月) 14:38:37 .net]
>>389
どう見てもSun信者です。お引き取りください。


395 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/01/05(月) 15:02:13 .net]
>>389
おまえ未だRISCが高性能だと思ってんのか。

396 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/01/05(月) 15:08:27 .net]
>>379
> Itaniumはねー絶対健全化できる

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

2つ問題がある。

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

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

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

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



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

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

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

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


399 名前:名無しさん@お腹いっぱい。 mailto:sage [2009/01/05(月) 15:13:23 .net]
あら人気スレ

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

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の最適化まぬあるによると増えたレジスタは使うなというw

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サポートに変更になったとか書き込みがあった。






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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<182KB

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