アカウント名:
パスワード:
Poulson: The Future of Itanium Servers [realworldtech.com]VLIWはすごく賢いコンパイラの存在が前提でしたが、思ったよりコンパイラが賢くならなかったのか人間様が思ったより手書きアセンブラにこだわりすぎたのか。
Itaniumが要求している「すごく賢いコンパイラの存在」が「入力データもなしにプログラムの結果を予測出来るコンパイラ」にほぼ等しいから最初から方向性を間違ってたアーキテクチャだったということでしょう。
http://ja.wikipedia.org/wiki/IA-64 [wikipedia.org]
> 欠点としては、プログラムの実際の動きはコード生成時に完全に予測できるとは限らないということが挙げられる。> 実際の動きは入力されるデータの内容に大きく左右される。> アウト・オブ・オーダー実行ロジックを持つ主流のCPUは実行時に実際のデータに基づいて決定できるのに対して、> コンパイラは入力データを推量することしかできない。したがって、コンパイラがCPUよりも予測を失敗する可能性がある。> つまりVLIWの性能はコンパイラの性能に大きく依存する。> VLIWはマイクロプロセッサのハードウェアの複雑さを低減する代わりにコンパイラの複雑さを要求するものである。
>入力データもなしにプログラムの結果を予測出来るコンパイラ今どきなJava VMみたいに動的リコンパイルするんでしょ?「静的コンパイルなんかダセェよ!」という方向性は間違ってなかったと思う。
??Itaniumは静的コンパイルだと思いますが。CPUが推論をせずに実行をするのがItaniumの一番の特徴ですよ。
いやだから、動的リコンパイラが予測や統計で最適化すればいい、という話。動的リコンパイラとCPUの両方で似たようなことをやるのはムダでしょ?
> 元々RISCですからデコード部分や並べ替え部分もシンプルになりそう
その程度で物事がうまくいくんなら UltraSPARC とかももっと絶好調だったはずでは?
ええ。UltraSPARCを作ってるのがIntelだったら絶好調だったと思うよ。
Intelの技術は他から見ると大人と子供で済まないレベル。
どちらも結局は人様が対応してくれないと使えないってのでは、自らが主流で無い限りは対応は希望薄になると判断したのかも。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
ItaniumもVLIWを捨てるそうで (スコア:2, 参考になる)
Poulson: The Future of Itanium Servers [realworldtech.com]
VLIWはすごく賢いコンパイラの存在が前提でしたが、思ったよりコンパイラが賢くならなかったのか人間様が思ったより手書きアセンブラにこだわりすぎたのか。
Re:ItaniumもVLIWを捨てるそうで (スコア:2, 参考になる)
Itaniumが要求している「すごく賢いコンパイラの存在」が
「入力データもなしにプログラムの結果を予測出来るコンパイラ」にほぼ等しいから
最初から方向性を間違ってたアーキテクチャだったということでしょう。
http://ja.wikipedia.org/wiki/IA-64 [wikipedia.org]
> 欠点としては、プログラムの実際の動きはコード生成時に完全に予測できるとは限らないということが挙げられる。
> 実際の動きは入力されるデータの内容に大きく左右される。
> アウト・オブ・オーダー実行ロジックを持つ主流のCPUは実行時に実際のデータに基づいて決定できるのに対して、
> コンパイラは入力データを推量することしかできない。したがって、コンパイラがCPUよりも予測を失敗する可能性がある。
> つまりVLIWの性能はコンパイラの性能に大きく依存する。
> VLIWはマイクロプロセッサのハードウェアの複雑さを低減する代わりにコンパイラの複雑さを要求するものである。
Re:ItaniumもVLIWを捨てるそうで (スコア:2, 参考になる)
ここでいう実際の動きとは、分岐とキャッシュミスとページフォールトなわけで、これら全てをうまく扱えるのがアウトオブオーダーだったという話。
VLIWではそれぞれIF-Conversionとプリフェッチと先行ロードで対応しようとしたが限度があったということでしょう。
実際OoOは完成された美しさすらあるよね。すくなくとも計算の本質に切り込んでいる。
Itaniumのようなインオーダープロセッサでも分岐予測で投機的実行を行う以上、結果をコミットする前になんらかのバッファに持つ必要があるし、バッファ持つんだったらOoOでいいじゃんということになる。スカウトスレッドでもいいけど、あれも本質的にはOoOだ。
ちなみにインテルが捨てるのはItaniumのインオーダーネスであって、VLIW(EPIC)を捨てるわけじゃないよ。
Re: (スコア:0)
>入力データもなしにプログラムの結果を予測出来るコンパイラ
今どきなJava VMみたいに動的リコンパイルするんでしょ?
「静的コンパイルなんかダセェよ!」という方向性は間違ってなかったと思う。
Re: (スコア:0)
??
Itaniumは静的コンパイルだと思いますが。
CPUが推論をせずに実行をするのがItaniumの一番の特徴ですよ。
Re: (スコア:0)
いやだから、動的リコンパイラが予測や統計で最適化すればいい、という話。
動的リコンパイラとCPUの両方で似たようなことをやるのはムダでしょ?
Re: (スコア:0)
Re: (スコア:0)
CPU内の回路リソースをいっぱい使っていたので、当時としてはその部分をCPUの外に出す
という思想も悪くなかったと思いますよ。
(実際何年か前までは、プロセスルールがより新しいx86よりも高い性能を叩き出していた
のですから)
CPUリソースに余裕が出たことで、out-of-orderに舵を切りなおしても問題もない状況で
しょうし、バイナリ互換は保つでしょうから通常のCPU以上には最適化もされていて、かつ
元々RISCですからデコード部分や並べ替え部分もシンプルになりそうだから、意外といい線
いくかもね。
Re: (スコア:0)
> 元々RISCですからデコード部分や並べ替え部分もシンプルになりそう
その程度で物事がうまくいくんなら UltraSPARC とかも
もっと絶好調だったはずでは?
Re: (スコア:0)
ええ。UltraSPARCを作ってるのがIntelだったら絶好調だったと思うよ。
Intelの技術は他から見ると大人と子供で済まないレベル。
Re: (スコア:0)
http://en.wikipedia.org/wiki/Profile-guided_optimization
Re:ItaniumもVLIWを捨てるそうで (スコア:1)
Re:ItaniumもVLIWを捨てるそうで (スコア:1)
Re: (スコア:0)
使えるようになっていますよ(そこがVLIWとは違うところ)。
1バンドルに3命令が入ってるけど、並列処理できる範囲は複数バンドルに渡って
定義できるから、演算器が少なければ少ないなりに、多ければ多いなりに使ってくれます。
Re: (スコア:0)
歴史的にはVLIWはマイクロアーキテクチャをもろに見せていたこともありましたが、ItaniumではきちんとISAを定義していますから(それがすなわちIA64)、実装を知ることなくソフトを書けます。
Re: (スコア:0)
どちらも結局は人様が対応してくれないと使えないってのでは、
自らが主流で無い限りは対応は希望薄になると判断したのかも。
Re: (スコア:0)