ItaniumをUNIXで使うスレ

**名無しさん＠お腹いっぱい。** · 2008/07/14(月) 19:44:39

実際に使ってみた人、どうよ?

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

**名無しさん＠お腹いっぱい。** · 2009/01/05(月) 22:47:24

おまえら仕事しろ

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 09:53:30

>>421
> 開発のしやすさがまるで違うんだわ。

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

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 10:17:57

>>423
じゃぁ何でx86が組込みに使われてると思ってんだ?

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 13:31:40

「使われてる」なんて言うほど使われてないよ。80186の類はいっぱい使われてるけどな。

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 13:43:25

SPARCとどっちが多い?

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 13:44:16

東芝のHD DVDレコーダーは、x86だったな。
80186とかそんな非力なのではなくて。

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 13:44:46

だから失敗したのか

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 13:46:44

そうだな。SPARCだったら大成功だったところだ。

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 13:50:17

HD DVDプレーヤーにMobile Pentium4 2.54GHzが積まれててﾜﾛﾀ。

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 13:59:37

そういうのはパソコンまるごとから削ったタイプのやつだな。
組込み全体から見たら僅かに過ぎんが.. もうひとくくりで語るべきじゃないだろな。
今後増えるだろし。

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 14:34:37

Itaniumの話をしてください

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 16:19:03

>>431
組込み全体の話なんかナンセンスだよ。
組込みのうちSPARCが使われている領域の話に限定しなよ。

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

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 17:21:52

「x86に将来性なし」ってのは別にオレが言ったことでもなく、
ここの誰が言ったわけでもなく、Intelが言ったことなんだが。
なんでこう諦めが悪いかなww
んでもって、そんな x86の諦め悪いやつがなんでここにいるんだ?
amd64のデキがよかった、Meromのデキがよかった、Atomのデキがよかった、
そんなことが「x86の将来性」ないのを覆した、とか思ってるわけ?
先延ばししただけでしょ、どうヒイキ目に見ても。

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 17:40:40

Intelが間違わないという保証があるわけじゃないな

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 17:52:44

>>434
お前、なんで必死なんだ?

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 18:19:52

命令セットがどうこうってのは20年ほど前の議論だよな
結果から言えば当時の人たちはトレンドを読み外したということでFA

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 18:43:40

何の話してんの?

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 18:46:11

分からないなら黙ってればいいのに

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 18:47:11

なんでそんなに必死なの? ..w

**432** · 2009/01/06(火) 19:22:22

Itaniumのことだけ書いてください

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 19:30:57

Itaniumの話か。

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

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 19:49:43

そうだな。その後 IA-64がコケたとしても、今とは別の展開があっただろう。
あんまり期待できんがw

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

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 20:01:52

IA-64の命令セットと、プロセッサの実装を、分けて考えないと。

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

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

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

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 20:27:44

Itaniumの一番ダメな点 = レジスタウィンドウもどきを実装していること。

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 20:48:30

Itaniumの一番ダメな点 = EPICじゃないの？

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 20:49:26

2001年頃にAMDが潰れてればx86からIA-64への強制的な移行が推進されたのかもな
今は”やっぱり命令セットは拡張できる方がイイヨネ！”って時代なのでありえない話

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 21:09:40

Intelが用意していた(AMD64ではない)x86の64ビット拡張は、IA-64とは違うものだったらしいですよ。

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 21:10:51

なんだかやる気のないやつね

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 21:35:18

どうせAMDにペースを握られたくないという理由だけで策定した間に合わせのものだろう
あるいはx86_64よりIA-64のほうがいいよねって流れに誘導したかったんじゃないかと

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 21:40:39

まあそれでもちゃんとキャッチアップしてCore2DuoとかCore i7出したんだから
結果的にはよかったんじゃないかな。

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 21:50:34

それにしたってAMD64は、ヤッツケ仕事すぎる。

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

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

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 21:54:06

まあインテルさんがIA64とかにかまけてないでまじめに
x86の拡張をかんがえてればよかったんじゃないのかなー
まあ状況的に無理だけど
だから次善の策としてamd64はよかったんじゃないかな

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 21:55:59

>>451
なんかIntelやばいんじゃね？と思ったら常勝の帝国軍へ戻っていた
な、なにを言ってるのかわからねーとおもうが(ry

**名無しさん＠お腹いっぱい。** · 2009/01/06(火) 22:03:21

x64だっけ?

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

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

**名無しさん＠お腹いっぱい。** · 2009/01/07(水) 07:04:56

オペコードが人間が綺麗と感じるように割り当てられてることにどんな意味があるの？

**名無しさん＠お腹いっぱい。** · 2009/01/07(水) 10:43:16

> オペコードが人間が綺麗と感じるように

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

**名無しさん＠お腹いっぱい。** · 2009/01/07(水) 10:43:26

デコーダがシンプルになる...いまどきどうでもよいが。
将来の拡張の余地が広がる。これは大きい。

**名無しさん＠お腹いっぱい。** · 2009/01/07(水) 10:45:34

AVXでおk

**名無しさん＠お腹いっぱい。** · 2009/01/07(水) 10:54:44

AVX?

あれ長いよ。

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

**名無しさん＠お腹いっぱい。** · 2009/01/08(木) 15:11:25

ほれ見ろ。オレがネタ投下してやんないとなんも出んがなw

**名無しさん＠お腹いっぱい。** · 2009/01/08(木) 15:13:49

安くて消費電力の少ないIta2マシンどっかに落ちてないかな
中古でいいよ

**名無しさん＠お腹いっぱい。** · 2009/01/10(土) 00:42:48

そんな製品がないんだから中古なんてなおさらあるわけないw
複雑化の原因はコンパイラにまかせてコアは単純化されてるはずだから
キャッシュ減らしたら電力食わないんだろ、きっと。そうに違いないwww

**名無しさん＠お腹いっぱい。** · 2009/01/10(土) 20:06:22

キチガイはスルーで

**名無しさん＠お腹いっぱい。** · 2009/01/10(土) 21:05:06

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

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

**名無しさん＠お腹いっぱい。** · 2009/01/10(土) 21:23:58

AMDを責めてもしかたないわな。
水先案内人としての責任は、牽引する立場のIntelにある

**名無しさん＠お腹いっぱい。** · 2009/01/10(土) 21:28:21

市場を完全に制圧してからやるべきだったね
その辺Microsoftは賢い

**名無しさん＠お腹いっぱい。** · 2009/01/10(土) 21:33:14

AMDはIntelの失敗を修正する役割があると

**名無しさん＠お腹いっぱい。** · 2009/01/10(土) 21:36:05

>>452
Intelの最適化まぬあるによると増えたレジスタは使うなというｗ

**名無しさん＠お腹いっぱい。** · 2009/01/10(土) 21:38:25

あはははは

**名無しさん＠お腹いっぱい。** · 2009/01/10(土) 22:12:26

>>467
そのほうが消費者の利益になったとしても、独占ってだけで叩かれるぞ。
個人的にはAMDのIA-64実装を見てみたかった。

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

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

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

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

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

**名無しさん＠お腹いっぱい。** · 2009/01/10(土) 22:22:44

命令長伸ばしてレジスタ拡張なんて最近流行の電力効率に反する実装だからだよ
AVXの目的もそういうことだ

**名無しさん＠お腹いっぱい。** · 2009/01/10(土) 22:32:30

やっぱり、64ビット拡張するときに、OPコードを大胆に整理すべきだったんだよ。

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

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

**名無しさん＠お腹いっぱい。** · 2009/01/14(水) 01:57:08

なんか自作板にTukwilaはDDR3サポートに変更になったとか書き込みがあった。

**名無しさん＠お腹いっぱい。** · 2009/01/14(水) 12:11:19

そうなればそうなるわな

**名無しさん＠お腹いっぱい。** · 2009/01/14(水) 12:58:33

以前からDDR3系のFB-DIMM2も対応予定に入ってなかったっけ？
それともFB-DIMM1のサポート無くしたという意味かな。

**名無しさん＠お腹いっぱい。** · 2009/01/14(水) 16:18:08

え?

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

**名無しさん＠お腹いっぱい。** · 2009/01/14(水) 16:39:30

2007年の時点で、
DDR3を使ったFB-DIMMの提供予定はない
っていう話だった。

**名無しさん＠お腹いっぱい。** · 2009/01/14(水) 16:40:48

FB-DIMMやめて直にDDR3のメモリコントローラを積むって話では?

**474** · 2009/01/14(水) 22:32:03

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

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

**名無しさん＠お腹いっぱい。** · 2009/01/14(水) 23:08:59

へー、直結にするんか。
まあ、その方がレイテンシ短くできるだろうし、やるかどうか怪しいけど
Xeon-MPとのプラットフォーム共通化も進めやすいだろうし。

それで発売が遅れてるんだったら、まあ建設的な理由だな。

**名無しさん＠お腹いっぱい。** · 2009/01/15(木) 03:06:16

そもそもFB-DIMMって、
メモリコントローラをチップセットに持たせた時に、
大量のメモリを積むためのもの。
チップセット1つから、メモリのバスを12本とか出せないんでね。

ところが

QPIを導入した時点で、
CPUの数だけメモリコントローラを増やすことができる。

メモリのバスを3本もつCPUを4ソケット構成にすれば、
無理なく12本のメモリバスが得られる。

**名無しさん＠お腹いっぱい。** · 2009/01/15(木) 03:13:48

DDRのままではコア数はどんどん増えるのに帯域はあまり稼げないしピン数も爆発的に増える。
シリアルメモリは絶対必要。なのにFB-DIMMは死んでDDR4はどんどん先送りされている。
Nehalemでは痛みに耐えて3chにしたけど1年後には6コアのWestmereが来る。焼け石に水。
高速なローカルメモリの使えるLarrabeeでどうにかなるという読みなのかね。

**483** · 2009/01/15(木) 03:25:32

忘れていたが。。。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の方が低いと思うが。

**名無しさん＠お腹いっぱい。** · 2009/01/15(木) 09:06:15

>>483
Larrabeeは、普通のCPUを置き換えるようなものではないと思う。
少なくとも、エンタープライズのサーバのCPUの置き換えにはならない。

>>484
それは大容量のL3やL4のキャッシュを乗せようという話だと思います。

**483=484** · 2009/01/15(木) 22:37:30

>>485
>Larrabeeは、普通のCPUを置き換えるようなものではないと思う。
>少なくとも、エンタープライズのサーバのCPUの置き換えにはならない。
うん、それはわかっている。
帯域が必要な分野にはLarrabeeを充ててキャッシュでそこそこ何とかなるサーバー向けCPUはのんびりいくのかなと。
Montecitoなんか未だにFSB533MT/sだもんね。144bitバスとは言え。。。

>大容量のL3やL4のキャッシュを乗せようという話
IntelのスライドによるとSandyBridgeのon-package memoryの容量は512MBとかだから従来のキャッシュとは桁が違う感じ。
これだけ容量が大きくなると制御法も従来の延長では駄目で一工夫要ると思われる。。。要するにキャッシュになるのかわからない。
まあ古いスライドなので変更された可能性もあるんだが。。。

スレ違いなのでこの辺で。

**名無しさん＠お腹いっぱい。** · 2009/01/15(木) 22:45:35

FSBのデータバスの転送だけ速くしても、アドレスバスの処理能力が先にネックになったら無駄なわけで。
そのあたりは難しいよね。

データはとにかく転送すりゃいいんだけど、アドレスは処理しなきゃならないから。

**名無しさん＠お腹いっぱい。** · 2009/01/16(金) 13:59:49

NECのＡＣＯＳ使ってるけどやっぱ、古いよな？

**名無しさん＠お腹いっぱい。** · 2009/01/16(金) 14:01:15

それで済むならそれでいいじゃん

**名無しさん＠お腹いっぱい。** · 2009/01/16(金) 19:56:37

電気代考えると..

**名無しさん＠お腹いっぱい。** · 2009/01/16(金) 20:01:13

電気代の差額ｘこれからの使用年数　が導入費用と同じ桁になるなら考えてみれば

**名無しさん＠お腹いっぱい。** · 2009/01/16(金) 20:58:10

いや。所有者のコストじゃなくて地球のコスト。

**名無しさん＠お腹いっぱい。** · 2009/01/16(金) 21:11:36

新規導入しないほうがいい

**名無しさん＠お腹いっぱい。** · 2009/01/17(土) 13:11:38

移行に失敗したときのリスクも考えよう。

現状のランニングコストと導入コストが一緒だから、
タダでシステムが新しくなりますよ?
なんていうセールスはアヤシイ

**名無しさん＠お腹いっぱい。** · 2009/02/02(月) 12:06:16

「ＸＸなんていうセールスはアヤシイですよ」っていうやつがもっとアヤシイ。

**名無しさん＠お腹いっぱい。** · 2009/02/05(木) 01:02:27

Intel delays Itanium upgrade to add new capabilities
http://www.networkworld.com/news/2009/020409-intel-delays-itanium-upgrade-to.html

**名無しさん＠お腹いっぱい。** · 2009/02/09(月) 04:41:33

>>496
Sunの広告が表示されるページの内容なんて・・・

**名無しさん＠お腹いっぱい。** · 2009/02/09(月) 07:03:05

あははははは
広告って効果的だね！

**名無しさん＠お腹いっぱい。** · 2009/02/11(水) 19:42:05

Tukwila、もう出ないんｼﾞｬﾏｲｶ。
http://www.atmarkit.co.jp/news/200902/09/intel.html

**名無しさん＠お腹いっぱい。** · 2009/02/12(木) 10:51:40

いよいよ i960が 64bit、QPIになって復活します。

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 10:55:34

次世代 ISAのために HPと組む、というのはもう失敗したので、
次どっかと組む必要ありだろうな。
ARMは捨てちゃったし。Alpha買ってくる、とかw
いずれにせよ、もう新しい ISAを定義する必要はない。
POWER対抗、という軸で考えると、SPARCという選択肢もあるかもw?

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 11:07:16

SPARCみたいな変態アーキ使うくらいだったら、
素直にそのままIA64で続行してても大して変わらないし、
SPARCのインストールベースを狙いたいんだったら、
x86でItaniumクラスのCPU作る方が遙かに良いだろ。

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 11:56:34

IA-64はオープンソース方面がぜんぜん関心示さないのが致命的でしょ。
性能出せるコンパイラーが CPU開発してる近辺からしか入手できないという
ことだと、利用が拡がらない。

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 12:27:42

しかし、それを言い出すとやっぱりx86 ISA最強になってしまうだろう。
それにこのクラスのCPU使う所って、そんなにオープンソース使うか？
エンプラに限らず、ハイエンドから組み込みまで狙うっていう話だったら
別だけどね。

そのエンプラでさえIA64が流行らない最大の理由はintelのやる気の
なさにつきるだろう。
POWERだって一時はイマイチだったけど、POWER4あたりからの
IBMの気合いの入れっぷりを見て皆ついて行って、成功したんだし。
2～3年に1回、ライバルに対して半世代遅れな性能の製品しか出て
こない様では誰もついて行かないよ。

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 12:30:06

>>501
AlphaってHPじゃんw

そもそもItaniumみたいなVLIWならともかく、
古典的なISAをまた始める意味は全くないでしょ。
箱ごと売っているSPARCとPOWER以外は死滅したわけだし。

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 12:32:05

>>504
やる気はあったけど、うまくいかなかったんだよね。
なにしろSunまでItanium Solaris出してたんだから。

**504** · 2009/02/13(金) 12:40:26

>>506

Solaris/ia64は計画段階でやめたんじゃ無かった？

intelもMadisonだした直後くらいまではやる気あったと思うけど、
その頃からx86でAMDに押されまくって、IA64なんて言ってる
騒ぎじゃなくなってからの放置っぷりが酷すぎる。

んで、Core MA出てからは、もうサーバーもこれで良いんじゃないという
流れになって、ますますやる気ナッシングに。
そして、今度出るNehalem-EXとか見るとRASもかなり意識していて、
もうIA64やる気無いだろうと思ってしまう訳で。

**504** · 2009/02/13(金) 12:45:20

あとは個人的妄想だけど、NECと共同出資で富士通あたりが引き取れば
いいのにとか思ってしまう。
レジスタウィンドウもどき持っている辺り、SPARC 64と同じ変態系だしなｗ

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 13:10:24

>>503
オープンソースな人たちはgccを使うわけだが、そのgccの生成するIA-64のコードが酷かった。
さらに人間がバイナリレベルでデバッグするのが難しく、さらに、マシンチェック回りはアマチュアには無理。
つーわけで、オープンソース方面ではIA-64バッシングが激しかったんだよ。

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 13:15:59

>>505
> そもそもItaniumみたいなVLIWならともかく、

いやいや、VLIWがやっぱり長期互換性の必要な ISAとしてはダメってことを
証明したんでしょ、Itaniumがさ。

> 古典的なISAをまた始める意味は全くないでしょ。

RISC最強w

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 13:17:17

>>509
つまりそれは「バッシング」じゃなくて、「正しい見解」、じゃんか。
しごくまっとうな言い分だと思うけど。

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 13:19:12

>>509
最後の一行は君の妄想だと思うw

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 13:23:17

>>510
いえいえ、x86最強でしょう。

ARM - x86 - POWER(SPARC)の棲み分けでいいんじゃないでしょうか。

しかしIntelは、x86の省消費電力で出遅れたり、
経営戦略の方がさっぱりですね。

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 13:23:23

>>505
HPとSamsung（とAPI）が持っていると思われる権利をある程度買ってくれば
なんとかなるかもね

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 13:30:58

>>510
静的最適化の世代間互換を諦めていれば、性能はともかく
バイナリ互換は残せるので、もっと早く進歩できたと思うんだけどね。

最初に短いパイプラインで出してしまったので、それを前提にした静的
最適化の効果を残そうとすると、パイプラインを長くする事ができなくて、
クロックが伸び悩んだというのが躓き始めだと思う。
かといってOoO実行に走ると、そもそもEPICの意味がってなるしね。

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 13:34:44

Samsungへのライセンシングは終了してるんじゃないのかな。

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 13:39:58

>>515
「静的最適化の世代間互換」は、今から諦められないの?
要は、バイナリ互換だけど昔コンパイルしたバイナリは遅い、ってことよね?
まあ、そんな珍しい話でもないよね。程度もんだけど。

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 13:42:57

>>514
なんか、DECの残党かき集めたやつが勝ち、みたいな雰囲気感じるんだけど、
気のせい?w

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 13:47:06

>>517
マルチコア、マルチタスク環境下で混在すると、
うざいことこの上ない。

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 13:53:01

>>517

OoOプロセッサだと最適化世代が違ってもそれなりに動くが、
インオーダプロセッサだと性能の落ち方が大きいし、あとまあ
519の言うような事もあるだろうな。
ということでHPが嫌がって、アグレッシブプランは葬り去られた。

**名無しさん＠お腹いっぱい。** · 2009/02/13(金) 13:58:53

古いパイプラインのエミュレータを置けって事だからね。
iOにした利点の全てが吹っ飛ぶ。>>515と並行関係にある問題。