いまだにIBMにあこがれるIntel

クアッドコアIA-64プロセッサ「Tukwila(タックウイラ)」

http://pc.watch.impress.co.jp/docs/2008/0208/kaigai418.htm



RISC vs CISC の論争は、命令デコードに多段パイプラインが導入されて変換やらout of order とかが導入された時に無意味になったと思う。PowerPCなんか泣いちゃうほど複雑だし。でも、VLIWはだめなアイデアだってのが僕の持論。



32bit命令を三つたばねて128bit命令にしたのがIA-64のVery long instruction set。こいつをコンパイラレベルでハードウェアに最適に並べ換える。一種の水平マイクロなので、チップ内部で使うなら良いんだけどさ。



もしIA-64がIBM 360みたいにマイクロコードレベルで互換性があって、あらゆる命令の実行クロックが将来に渡って同じだったら、それでも良かったと思う。でも、現実には、どんどん異なるハードウェアが出て来てしまう。実際、VLIWのバイナリ互換は制約でしかない。その時その時のデバイス技術で、どういう命令(VLIWの一部)が速く実行できるかなんて変わってしまう。マシンが変わるたびにソースからコンパイルし直すの? JIT/Runtime compile っていう手もあるけど、最適化にかけられる時間は限られてしまう。



命令レベルの並列性(ILP)に予測性があるってのも嘘だと思う。実際にはキャッシュがあるわけだから、load/store のタイミングは本質的に予測不可能。結局、20年前のデルコネアHEPみたいに、予測不可能な遅延をスレッドレベルの並列性(TLP)で吸収する方が効果がある。命令レベルの並列性は3-4程度なので、キャッシュとメインメモリのアクセス時間差を吸収できるほどではないってことでもある。



CPU同士が継るQuick Pathが結構たくさん用意されていて、キャッシュを介したコストの高いspin lockよりもハードウェア的、ソフトウェア的に軽くて高速なInter-thread 通信が可能になっている。でも、それ自体、予測不可能な要素なので、VLIWと両立しない。さらに、CPU同士が密に継って動くアプリケーションって極めて難しい。不可能だとは思わないけど、プログラミングパラダイムから変えてかないと書けないよ。それで動作クロックがあがるというなら、まだ理解できるんだけど、実際には逆だし。



それでも、IntelがIA-64にしがみつくのは、やっぱりメインフレームに対するあこがれがあるからなんだと思う。ハードウェアとソフトウェアの複雑さ、コンパイラ技術、バイナリ互換性、大規模なチップ、大規模なサーバ。ハードウェア会社は、やっぱりメインフレームが一番儲かるからね。