ＰＣ関連スレ - 1036414893 - したらば掲示板

17：■とはずがたり：2002/11/23(土) 22:23: 次世代Crusoeのパフォーマンスは本物か（2/2）

Transmetaによると、TM8000用の256ビット命令用CMS は、従来の128ビット命令用CMSをクロスコンパイラで256 ビットで動作するようにし、それに最適化を図る手法では開発を行わなかったという。実績のあるCMSを捨て、新たに全く別のCMSを新アーキテクチャにフィットさせながら、スクラッチから作り上げた。

しかも現在の256ビット命令用CMSは、まだパフォーマンスチューニングを十分に行っておらず、後述するCMSの高速化テクニックも利用していないという。まだファーストシリコンが上がったところで、テストの中で最適化を進めていけば、来年第3四半期と言われるTM8000のリリースまでには、さらなる速度向上が進むことだろう。CrusoeはCMS次第で、パフォーマンスがいくらでも変化するからだ。

例えば、TM5600時代と現在のTM5800はチップのアーキテクチャは全く同じだが、現在のパフォーマンスはクロック周波数以上に改善されている。それだけでなく、PCベンダーが調達した時期によってCMSのバージョンも変わるため、わずかではあるが同時期に販売されているCrusoe機でも、メーカーによってパフォーマンスが異なる。

もうひとつ興味を引いたのが、同じ富士通「LifeBook」を2台並べてアプリケーション起動速度などを計測するデモンストレーションだ。2台に実装されたCrusoeはどちらも同じクロック周波数で動作している。ところがアプリケーションの起動速度や起動直後のレスポンスが明らかに異なる。高速な方のCrusoeには、まだリリースされていない新しいCMSが使われているからだ。

新CMSが高速な理由は、Crusoeがアプリケーションのコードを実行するプロセスの中にあるようだ。具体的な仕組みに関しては一切話をしてもらえなかったが、いくつかのヒントから推測すると以下のような理由だと考えられる。

CrusoeのCMSは、初出のx86コードが実行されると、それをアトムと呼ばれる細かな命令に分割し、最大4個の命令で構成されるVLIW命令に変換、実行される。しかし初回の実行ではほとんど最適化は行われず、アトム生成時に並列実行できることがあらかじめわかっている命令しかVLIWへとまとめられていない効率の悪いコードだが、これをそのままCMSが管理するキャッシュ領域に保存しておく。

実際に最適化が行われるのは、プログラムコードが2回目に実行される時で、このとき初回に翻訳されていたVLIW命令を再構成して並列度を高め、初めてCrusoe の能力が発揮できるようになる。最適化されたコードは以前のコードと置き換える形でキャッシュに保存され、次回実行時にさらに最適化が進められる。

最適化されたコードで動くときのCrusoeは、実は現在言われているほど遅くない。Crusoeが体感的にもベンチマークでも特に遅くなってしまうのは、初出時のコードが十分に最適化されるまで何度かのループが必要になることと、初回の翻訳されたコードがほとんど最適化されていないためアプリケーション起動時の初期化プロセスなどが遅いためだ。

最適化されたコードを保存する領域は（CMS本体の作業領域も含め）16Mバイト、一部機種で24Mバイトとなっており、ここからあふれたコードは最適化プロセスを最初からやり直さなければならない。

逆に言えば初回実行時から最適化されたコードならば、Crusoe独特の「もっさりとした」動きだしの悪さはなくなる。

新CMSが使っているのは、おそらくFX!32と同等のテクニックだろう。FX!32はWindows NT上でx86命令をAlphaプロセッサ命令へと変換・実行するソフトウェアだったが、一度変換したコードをハードディスク上にキャッシュとして展開する機能を持っていた。

新CMSの場合はハードディスク上にx86のOSからは見えないパーティションを生成しておき、そこにOSを介さずダイレクトに最適化後のコードをキャッシュしておくことで、コード初回実行時にアトムへの変換を行う代わりに、キャッシュをメモリ内にロードしているのではないだろうか？全くその通りかどうかはわからないが、Transmetaの担当者はそうした推測を否定しなかった。

http://www.zdnet.co.jp/news/0211/22/nj00_astro_2.html