AMD、VLIW を捨て、新グラフィックスアーキテクチャへ移行 46
ストーリー by reo
いよいよもって VLIW はいらない子なのか ? 部門より
いよいよもって VLIW はいらない子なのか ? 部門より
cvmonto 曰く、
AMD が、Radeon HD 2000 から続く VLIW アーキテクチャを捨て、新しいグラフィックスアーキテクチャへ移行するとのこと (4Gamer.net の記事より) 。
AMD Fusion Developers Summit で発表されたことのようだが、非同期タイプの「Compute Engine」を複数搭載してマルチタスク性能を引き上げることや、VLIW における Thread Processor に相当する「Compute Unit」に 4 基の 16-way の SIMD コアと 1 基のスカラ演算ユニットを搭載することなどが明らかにされたとのことである。
続報 (スコア:3, 参考になる)
一部モデルにおいては年内に市場投入されるとか(4Gamer.netの記事 [4gamer.net])。
アーキ移行とプロセス移行を同時に行うギャンブルはしないと仮定すれば、VLIW系最終製品(6950/70改良?)+プロセスシュリンクの堅実な製品を選ぶか新アーキ+現行プロセス(うまくいけば性能のジャンプアップ、ただ消費電力もすごそう?)のチャレンジャブルな製品を選ぶかの二択問題でしょうか。
RYZEN始めました
Re:続報 (スコア:2, 参考になる)
後藤弘茂のWeekly海外ニュースのAMDが革新的な次世代GPUアーキテクチャの概要を発表 [impress.co.jp]もあわせてどうぞ。
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)
案外早かった (スコア:2, 興味深い)
OSのサポートがないと無理、って後藤たんの記事にありましたから、どこが一番先になるかは気になります。
私の妄想では、存在していればBeOSだったと思う。
そして誰もしなくなった (スコア:1, 興味深い)
思えばCrusoe [wikipedia.org]もVLIWだったよなぁ…
結局「泥臭い」と言われ続けたx86が、今もしぶとく生きつづけてる現実をどう解釈すればいいのだろう？
Re:そして誰もしなくなった (スコア:1, 興味深い)
・人間様の「僕が一番うまく機械語を使えるんだ」という信念
じゃないですかね。RISCやVLIWは人間が直接書くには辛すぎましたからね。
Re:そして誰もしなくなった (スコア:3, すばらしい洞察)
>じゃないですかね。RISCやVLIWは人間が直接書くには辛すぎましたからね。
人間だけでなく機械にも辛すぎたって事じゃ。
もしかしたら機械に出来るのは人間が考えられるロジックのみってのを忘れてしまっていたのかも。
Re: (スコア:0)
高性能プロセッサは確かにCISC命令セットであるx86の天下になりましたが、これは人手で
書きやすいという理由ではなく、初期に圧倒的シェアをとり、それ以来互換性をとり続けて
きたのが理由でしょう。
より人手でアセンブリ言語のプログラムを書くことが多い組み込み分野では
x86よりもARMやSuper-HのようなRISCプロセッサの方が主流です。
こちらも書きやすいからというよりはプロセッサ価格とか電力消費が理由ではありますが。
Re:そして誰もしなくなった (スコア:1, 興味深い)
以前は搭載メモリ容量の小ささやCPUの遅さや周辺機能のリアルタイム性といった主にハードウェア制約からアセンブリ言語でカリカリにチューニングしていたものですが、今はメモリも十分積んでるし、コンパイラの性能向上、プログラムの可読性や可搬性などで高級言語(といってもC言語がほとんどですが)が主流です。
CISC、RISCという点はミドルレンジからハイエンドはRISC CPUですが、圧倒的多数を占めるローエンドはCISCですよ。
ローエンドもRISCでは (スコア:2)
＞CISC、RISCという点はミドルレンジからハイエンドはRISC CPUですが、圧倒的多数を占めるローエンドはCISCですよ。
代表的なローエンドCPUを列挙し、調べてみました。
PIC：RISC (確認先：PIC10F200 8bitマイコン)
AVR：RISC（確認先：ATtiny13 8bitマイコン)
8051：仕様書には明記無し。あえて言うなら8051。
H8：CISC（16bitマイコン。仕様書に明記無かったが、多数のルネサス社資料に明記)
ARM：RISC
明らかにCISCなのはH8だけで、あとは8051がCISCっぽく見えるくらいですね。
ローエンドでもRISCが主流に見えます。
Re: (スコア:0)
RXシリーズはCISCですね。
http://www.kumikomi.net/interface/contents/201107.php
特集の第4章にかなり詳しく載っています。
ARMは本当にRISCなん？ (スコア:0)
thumbとARMモードは命令一発で切り換えられるし、
prefetchで投入される命令群をストリームとして見ると、CISC的発想な気がする。
CISC並に分岐命令は複雑だし。
# TLBのしょぼさと、ディレイスロットがないのと、即値関連のヘボさがきらい
Re:ARMは本当にRISCなん？ (スコア:1)
＞ARMは本当にRISCなん？
＞CISC的発想な気がする。
気がする、で語られましても。
メーカーが「RISCです」って言ってます。以下、例。
ARM9 [arm.com]：The ARM926EJ-S™ processor features a Jazelle® technology enhanced 32-bit RISC CPU
CORTEX M0 [arm.com]RISC processor core High performance 32-bit CPU
Re: (スコア:0)
んなこたあ、百も承知ですがな。無粋な
ALUじゃなくてPrefetchでみたら、RISCの定義から外れるでしょう
という雑談すらできん雑談サイトとは、これいかに。
Re: (スコア:0)
Re: (スコア:0)
>> より人手でアセンブリ言語のプログラムを書くことが多い組み込み分野では
> 組込MCUも今はC言語で書くのが普通ですが。
ブートローダの初期化部分とか、ＯＳのカーネルの一部分とか、割り込みハンドラの
まさに飛んでくる所とかはアセンブラで書かざるを得ない部分がある、ということを
言ってるんじゃね？
ｘ８６を使うプロジェクトならこういう部分にまったく触らずに進められるかもしれ
ないけど、それ以外の組込みのプロジェクトだと多少なりともハードウェアカスタマ
イズが入るので、触らずに済むことが少ないでしょうし。
もっともそういうレアな部分のコードはもはやソフト開発者は書かない（知らない）
のかもしれない・・・。「アセンブラがわかるソフト開発者が絶滅した」という理由
で、ＯＳの移植やソフトウェアのコンパイル環境とかはハード開発者がやってる会
社もあるというし・・・。
Re: (スコア:0)
Pure RISC 勢の性能アドバンテージが小さくなり、
シェアに優れる x86 勢に太刀打ちできなくなったというのも大きいでしょう。
Pure RISC 勢が当初勢力を持っていたハイエンド部門に関しても、
x86 を売りまくり資金力が潤沢な Intel に対して研究開発および生産設備面で
対抗することが難しくなり、Alpha や PA-RISC は終息、SPARC も元気がなく
POWER がかろうじて意地を見せているといった現状でしょうか。
x86 が弱い組み込み部門では ARM をはじめとする RISC が優位を保っていますが
今後はどうなっていくんでしょうね。
# まぁ x86 が下に伸びるとは考えにくいですが
Re: (スコア:0)
○ 商用化された RISC 勢
商用化された Pure RISC なんて存在しない
Re: (スコア:0)
> 商用化された Pure RISC なんて存在しない
商用化されてなくてもいいから、Pure RISCの例を挙げるんだ。君には無理だろうが。
Re:そして誰もしなくなった (スコア:1)
Re: (スコア:0)
安易にマクロを使えないという制約以外、なんてことないですよ
Re: (スコア:0)
i860のパイプラインモード対応の割り込みハンドラをアセンブラで書いてみてくれ。
Re:そして誰もしなくなった (スコア:1)
そのうち，Itaniumの命令を，動的コンパイラーがEM64Tに書き換えるようになるのですかね。
その方が動的コンパイラーも楽そうですか。
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
10年前の時点でRISCすら最先端の命令セットとは言えなかったわけで
その差を埋めようとしたらスケジューラ強化しないといけない。
そうなるとCISCに対する命令デコーダの優位性も下がってしまう。
で、VLIWに発展したけどこれも時代遅れになってきてて
しかも今度は命令セットで吸収するのは無理っぽい。
結局はRISCに負けじとスケジューラ強化の先陣切ってた
CISCが有利になってるって言うのが現状じゃないかな？
Re: (スコア:0)
かといって昔のRISCのように単純すぎる命令セットも抽象度が低すぎる。
たとえばPowerPCのようにループカウンタは特別なレジスタとして扱えば、カウンタをフロントエンドに持っていってループ命令のフェッチと同時に参照できるので、分岐予測ミスは起きないようにできるし、分岐予測テーブルエントリを消費しないというメリットもある。
なのでリッチなRISCが抽象度の高さとデコードの容易さのバランスがとれていてベストではないかと思う。
昔はマイクロコードで抽象度の高いISAを実現していたが、今はハードワイヤードで実現しているというわけ。
プログラミング言語と同じで、抽象度が低すぎると実装の自由度が下がるのでよくない。
IA64はVLIW的な側面以外にも見るべき点は多いので、まとめてポイされてしまうととても悲しい。
VLIW(除くEPIC)はRISCからさらに先祖がえりして抽象度が低いんでね…
Re: (スコア:0)
結局「泥臭い」と言われ続けたx86が、今もしぶとく生きつづけてる現実をどう解釈すればいいのだろう？
我々の遺伝子も結構泥臭いと思う。
母体内で胎児が進化を再現するのとか見ると。
UNIXやLinuxの系譜を見て、まるで系統樹みたいだなーと思わないでもない。
素人視点での予想 (スコア:1)
Re: (スコア:0)
その理由じゃないですかね。
アルゴリズムがいつも変わるようなものだとVLIWのほうがいい気がするし、
もう欲しい演算器が決まってるなら、SIMDのほうがいい気がします。
変遷的にはDSP->FPGA->ASICみたいなもんかな、と。