2002年に登場する次世代の256bit版こそが“真のCrusoe”だ。というのは、Crusoeアーキテクチャの利点は256bit幅の命令長でないと生かされない。

　Crusoeアーキテクチャのポイントは、x86命令をCrusoe独自のVLIW命令に変換することで、命令レベルの並列化(Instruction-Level Parallelism:ILP)をx86の世界にもたらすことにある。ILPの効用とは何かというと、1サイクルで実行できる命令数(instruction per cycle:IPC)の向上だ。

　x86アーキテクチャでもRISCアーキテクチャでも、命令実行の並列化は、CPUが実行前に命令を並べ替えるという仕組みで行なっている。だが、この方法ではIPCは上がっても2.5命令/サイクルが限界と言われている。これは、CPU業界の常識らしくて、Intelの人に聞いてもRISCの人に聞いても同じ数字が返ってくる。

　それに対して、ILPアーキテクチャでは、コンパイラがプログラムのコンパイル時に並列に実行できる命令の並べ替えを行なう。この時に広域にコードを見て、複雑なスケジューリングを行なうことができるため、これまでよりはるかに高いIPCを実現できるというわけだ。もし、ILPアーキテクチャで5命令/サイクルを実現できれば、同じクロックでもx86 CPUよりも性能は2倍にできることになる。

　だが、これまではILPを実現しようとするとCPUの命令セットから変えなければならないため、従来のソフト資産との互換性が取れないという問題があった。IntelのIA-64は、x86命令のデコード&スケジューリングハードウェアを搭載するという荒技でこれを解決したが、x86命令を実行する際にはILPの効果はなにも生きない。ところが、Crusoeのアプローチはそれとは全く違う。「命令セットをソフトウェアでインプリメントした」(デビッド・ディッツェルCEO、Transmeta)ため、原理的にはx86命令を実行するのにILPの効果を活かすことができる。この、「x86でILP」というのがCrusoeアーキテクチャの最大の特徴だといっていい。

　Crusoeは整数演算性能で、同クロックのPentium III/Celeronの80%程度(プログラムによって違う)であり、これはPCの世界では低いと見なされているが、CPUのアーキテクチャを考えると驚異的な性能だ。このアプローチでこの程度の性能が出せるのなら、IA-64だってソフトウェアオンリーのアプローチでx86互換性の問題を解消できたことになるからだ。だから、Crusoeの登場で、いちばんいやな気分になったのはIA-64のスタッフではないかと思う。

●次世代Crusoeは5命令/サイクル以上に

　もっとも、従来のCrusoeは、命令長が128bitで命令スロットが4スロットだったために、VLIWといってもILPの特徴はぜんぜん出し切れていなかった。1サイクルで実行できる命令数(instruction per cycle:IPC)はそれほど高くなかったのだ。これは、128bit幅のこれまでのCrusoe命令では、最大4命令しか同時発行できない(実行ユニットは5個)からだ。Transmetaのジェームズ･チャプマン(James N. Chapman)上級副社長(Sales & Marketing)によると、現在のCrusoeのIPCの典型値は2.2命令/サイクルだという。これはCrusoeの内部命令「atom」の数と見られるため、x86命令になるとさらにこれより少ない(x86命令が複数のatomに分解されることが多いため)はずで、それでは従来のx86 CPUとほぼ変わらない。

　しかし、256bit化によって命令スロットが8スロットになる次世代Crusoeでは原理的にIPCは上がる。Transmetaによると、IPCの典型値は現在の2.2命令/サイクルから次世代Crusoeでは5命令/サイクル以上へと跳ね上がるという。つまり，同じクロックであっても次世代Crusoeは現在のCrusoeの2倍の性能になるということだ。4命令/サイクル以上がILPの目標だと考えると、Crusoeは256bit化でようやくILPアーキテクチャが活きる領域に達することになる。これが冒頭で書いた、256bit版こそ真のCrusoeという意味だ。

　また、これは，Pentium 4やPentium IIIよりもクロック当たりの性能が高くなる可能性があることも示唆している。今のx86 CPUのIPCの平均値は、最大で1.x～2.x命令/サイクル(コードによって大きく違う)だと言われているからだ。

●同じVLIWのIntelは5命令/サイクル以上を否定

　しかし、ここには疑問もある。というのは、CPU業界では、ここ1～2年、ILPに対する疑問が噴出しているからだ。

　例えば、ILPで5命令/サイクル以上が現実的かどうか。Intel Microprocessor Research Labs(MRL)のFred Pollackディレクタ兼Intel Fellowが、今年10月のPACT 2000で発表した 「New Challenges in Microarchitecture and Compiler Design」のプレゼンテーション資料には、スタティックなILPでは命令発行数をいくら増やしても実効IPCは、4.x命令/サイクルで止まってしまう(メモリボトルネックが全くない場合)という、MRLの研究結果が示されている。つまり、VLIWライクテクノロジで将来を切り開こうというIntelで、将来プロセッサ計画をディレクト('99年まで)していたPollack氏が、すでにILPの限界を言っているのだ。余談だが、このFred Pollack氏は、Intelの長期的なCPU戦略をウオッチする場合の最重要人物だ。えっ、Intelがこんなこと(例えば、Thread-Level Parallelismとかチップマルチプロセッサ)を考えてるの(!)という話が飛び出してくる。

　話を戻すと、ILPに関しては限界が見えてきていて、5命令/サイクル以上なんて行かないという予測もあるというわけだ。まあ、IPCはベンチマーク同様に、どういうケースの値かで全く変わってくるし、Crusoeはリアルタイムコンパイルを行なうため、Pollack氏のプレゼンとの比較は難しいが、ようは魔法のようには行かないということだ。しかも、Crusoeの場合は、経済的なチップサイズとメモリにするという制約もあるのでメモリでのボトルネックが発生しやすい。また、コードモーフィングソフトウェア(CMS)でリアルタイムにコンパイルするという制約もある。そのため、実効のIPCを本当に今の計画通り高めることができるかどうかには、まだ疑問がある。

　それから、Crusoeの場合は、実行ユニット数が増えてスケジューリングが複雑になればなるほどリアルタイムコンパイルにかかる時間も増えることになる。CMSによる最適化とそれでロスするサイクルはトレードオフの関係にあるはずなので、CMSの設計は激烈に難しい。しかも、そのトレードオフを検証するのも難しいはずだ。

　例えば、今のx86 CPUで20サイクルで実行できるあるコードブロックを、CMSが60サイクルで最適化して、Crusoeが8サイクルで実行できるVLIWコードにできたとする。その場合は、そのコードブロックが5回以上使われた場合には、Crusoeの方が速いが、4回以下だと最初の最適化の負担が大きすぎて遅くなってしまう。しかし、あまり最適化しないで、12サイクルかけて17サイクルで実行できるコードに変換すれば、今度は5回以下の実行なら速くなるが6回以上なら遅くなる。今のは根拠のある数字ではなく例にすぎないが、CMSはこうした判断を、スマートに行なわなければならないはずだ。もちろん、少ないステップで最適化するためのアルゴリズムを考え出すことも必要になる。

●LinuxをCrusoeのネイティブ命令にコンパイル

　ただ、Crusoeの利点は、CMSがダイナミックにコードの利用効率を見ながらコンパイルすることで、VLIWで難しい適正な最適化を行ないやすいことだ。例えば、Transmetaでは、LinuxをCrusoeのネイティブのVLIW命令にあらかじめコンパイルするという実験を行なった。しかし、あまり速くならなかったという。Transmetaのデビッド・ディッツェルCEOによると、その理由はCMSでリアルタイムにコンパイルした方が効率がいいからだという。以下がディッツェル氏の説明だ。

　「LinuxをCrusoeのネイティブVLIW命令に移植したと言うと、誰もが『それはずっと速くなるだろう』と言うんだが、そうではなかった。それは、CMSがうまく働くので、前もってネイティブにコンパイルしてもそんなに速くならないのだ。もう少し説明しよう。これは、直感的にわかりにくいだろうから。

　もし、あなたがCrusoeのネイティブ命令にOSのような大きなコードソースをコンパイルするとしよう。その場合、コンパイラは、コンパイルしてゆく過程でソースコードのどれが重要なラインでどれが重要でないラインかを知ることはできない。それは、静的なコンパイルだからで、その結果、どのラインも同程度の重要さを持つと考えて同じようにコンパイルすることになる。ところが、VLIWの場合には、これは必ずしも効率的ではない。最適化した方が性能が上がる部分もあるし、そうでない部分もあるからだ。

　それに対して、CMSは学習能力を持っていて、プログラムの実行のインフォメーションを集める。そして、コードを見ていて『ああ、ここの命令ではずいぶん時間を費やしているが、もっと最適化できる』と判断すると、その部分だけを最適化する。最高の性能を出せるように、最適化してゆくことができるのだ。また、CMSを使うと、プログラムはよりコンパクトなx86コードの形で格納しておくことができる。そうすると、ディスクの利用効率がよくなるし、読み出しも速くなる。

　確かに、こうした最適化のアルゴリズムを産み出すのは非常に難しい。しかし、CMSの開発にはリーヌス・トーバルズ氏のような非常に優れたプログラマたちが関わっている。彼らは、いい仕事をしていると思う。そうした優れたソフトウェアエンジニアが集まっているのがTransmetaの利点だ」

　なるほど、トーバルズ氏のような天才が必要になるわけだ。彼らがうまい仕事をできるかどうかは、2002年にわかることになる。

□バックナンバー

（2000年12月26日）

[Reported by 後藤 弘茂]