 |
|
●2002年には256bitの新Crusoe
 |
| ジェームズ･チャプマン上級副社長 |
現在のCrusoeの場合、まずCPUのソフトレイヤであるコードモーフィングソフトウェア(CMS)が、x86命令をRISCライクな単純命令「atom」(32bit固定長)に分解する。その後、その単純命令のうち並列に実行できる組み合わせを128bitのVLIW命令「molecule」にパック(実際にはかなり複雑なスケジューリングを行なう)している。つまり、128bit長ならatomを最大4個、ひとつのmoleculeに入れ込んで並列に実行することが可能だ。次世代Crusoeでは、このVLIW命令が256bit長になる。そのため、最大8命令をパック&同時実行できるようになる。
【従来Crusoeの命令】
| |32b | |32b | |32b | |32b| |
| |← 128bit →| | |||
【次世代コアCrusoeの命令】
| |32b | |32b | |32b | |32b | |32b | |32b | |32b | |32b| |
| |← | 256bit | →| |
この拡張で、Crusoe内部の実行ユニット数も8個以上に増えることになる。現在のCrusoeは整数演算ユニット(ALU)が2個、ロード/ストアユニット1個、ブランチユニット1個、浮動小数点演算/マルチメディアユニット1個の、5ユニット構成となっている。この5ユニットに対して、4つの命令スロットのatomを発行する仕組みになっている。
| |32b ↓ | |32b ↓ | |32b ↓ | |32b| ↓ |
||
| | ディスパッチャ | | |||||
| ↓ | ↓ | ↓ | ↓ | ||
| |ALU | |ALU | |Branch | |L/S | |FPU| | |
TM5400/5600では、浮動小数点演算/マルチメディアユニットは1個で、ベンチマーク結果などを見る限りこの分野の性能は非常にプアだ。これは、Transmetaのアーキテクトが、現在のノートPCでは整数演算が主体で使われると判断し、トランジスタを食う(=消費電力を増やす)浮動小数点演算ユニットをあえて犠牲にした結果だと見られる。だが、今後はノートPCでも整数演算はそれほど上げる必要がなくなる。そうすると差別化のポイントは浮動小数点演算/マルチメディア演算性能になり、この部分を強化する必要が出てくるというわけだ。浮動小数点演算/マルチメディアユニット自体の性能を強化するのと同時に、ユニットを複数にすると想像される。
●Crusoeのアーキテクチャに適したVLIW
256bit化はVLIWプロセッサであるCrusoeにとって適正進化だ。命令実行の並列化をソフトウェアが行なうVLIWでは、CPU側の進化は、同時に実行できる命令数を増やしてゆくことだからだ。それは、命令長を長くすることでもある。例えば、IntelのVLIWライクCPUであるIA-64プロセッサ「Itanium(Merced:マーセド)」では、3命令を格納した128bit長命令長を2つづつフェッチする。つまり、実質256bit幅分の命令を処理できるCPUであり、最大3×2＝6命令を同時に発行できる仕組みになっている。次のIA-64プロセッサ「McKinley(マッキンリ)」では、おそらく384bit幅(9命令)以上で処理ができるようになるだろう。VLIWプロセッサは、同じように進化して行くのだ。
また、命令長を長くすることは、x86をソフトウェアデコードするCrusoeのアーキテクチャにとって有利となる。というのは、Crusoeでは、分解したx86命令をVLIW命令にパックすることで、CMSの最適化処理の時間を稼いでいるからだ。例えば、もし、256bit Crusoeがx86命令8個を1つの命令語にパックできたとする。そうすると、8命令を順番に8サイクルかけてフェッチするのに対して、1サイクルでフェッチできるので7サイクルも有利になるのだ。実際にはPentium 4やPentium IIIは最大3命令をフェッチしているので、それほど稼げるわけではないが、VLIWアーキテクチャによってCMSが有利になっているのは確かだ。
●256bitでの性能はどうなる
では、256bit化で性能はどうなるのだろう。まず、浮動小数点演算/マルチメディア演算は単純に性能がぐんと上がるだろう。また、それ以外の処理でも、実行ユニットの数が増えることで、これまで実行ユニットの制約で並列化できなかったatomを並列に処理できるようになるため並列実行がしやすくなり、性能が上がる。ユニットが増えれば、条件分岐命令のふたつのパスを両方とも実行してしまう「プレディケーション(Predication)」的な処理も効果を出しやすい。Transmetaによると、同時に実行できる命令数は、現在が最大4なのに対して256bit Crusoeは8になる。また、命令実行数の典型値は、現在が2.2命令/サイクルなのに対して、256bit Crusoeは5+命令/サイクルになるという。
しかし、256bit化の効果が出るにはいくつかの条件が必要となる。まず、CMSが最適化スケジューリングを行なうには処理にある程度の時間がかかる。そのため、CMSはx86コードを最初に変換する際には、それほどガリガリには最適化しないらしい。まずは最短の時間でVLIWコードに変換、そのコードブロックをメインメモリ上のモーフィングキャッシュに格納しておく。そして、その同じコードブロックがキャッシュから再び読み出される場合にさらに最適化を行なう仕組みになっているようだ。今のCMSは、この多段階の最適化を2～3回行なうと見られる。だから、Crusoeでは同じソフトを使っていると徐々に性能が上がるという結果が生じる。
256bitアーキテクチャになると、原理的には、この最適化の度合いによる性能向上がより大きくなる。しかし、256bitの命令スロットをフルに活かすような最適化は、おそらくモーフィングキャッシュにいったん格納されたコードに対してでないとあまり適応できないだろう。そのため、何度も使うコードは256bit化で性能が向上するが、そうでないコードは、従来と比べてそれほど劇的には性能が上がらない可能性がある。つまり、実際に実行されるコードが局所的に偏在している(局在性が高い)ほど性能が出るというCrusoeの特徴がさらにはっきりしてくる。
それから、256bit化すると、CPUのフェッチ帯域を広くしないと性能が出ない。256bit幅命令でピーク性能を出すには、当然命令フェッチを毎サイクルごと256bitづつできないとならない。L1命令キャッシュは当然この帯域が必要で、L2キャッシュもできれば同等の帯域が欲しい。また、メインメモリ帯域も今よりもさらに必要になってしまう。
もっともメインメモリ帯域はどうやっても追いつきはしないので、カギはキャッシュの帯域と量になる。キャッシュの量の増加による、性能向上の幅が広がると思われる。そのため、キャッシュの量は、今よりもかなり多くする必要があるだろう。Transmetaのジェームズ･チャプマン(James N. Chapman)上級副社長(Sales & Marketing)によると256bit Crusoeは0.13μmプロセスで製造を始めるという。このプロセスで目標とする90平方ミリメートル以下のダイサイズ(半導体本体の面積)に納めるためには、(実行ユニット部分の面積は倍増するだろうから)おそらく1MB程度のL2キャッシュが限界ではないだろうか。だとすると、256bit Crusoeがターゲットとしているのは0.10μm以降で、2MBや4MBのキャッシュSRAMをOn-Dieで載せられるようになった時と考えた方がよさそうだ。それまでは、従来版Crusoeと256bit Crusoeが、PC市場でも併存することになるだろう。
【次世代Crusoeスペック】
| 同時実行命令数(最大) | 8命令/サイクル |
| 同時実行命令数(典型) | 5+命令/サイクル |
| 平均消費電力(典型値) | 0.5W |
| TDP(最大値) | 3-6.5W |
| ダイサイズ | 90平方ミリメートル以下 |
| プロセス技術 | 0.13μm |
| クロック | 1GHz～? |
（2000年12月25日）
[Reported by 後藤 弘茂]