|
●精度を上げるBaniasの分岐予測
Intelの次世代モバイルCPU「Banias(バニアス)」は、徹底してムダを省くことで、パフォーマンス/電力を高めるアーキテクチャを取る。そのポイントは大きく分けて4つある。
(1)ムダなマイクロOPs(Micro-OPs)の削減
マイクロオプスフュージョン(Micro-Ops Fusion)
スタック専用マネージャ(Dedicated Stack Manager)
(2)ムダな投機実行や分岐予測ミスの削減
分岐予測の強化
投機実行の最適化
(3)強力な電力管理
細分化されたハードウェアクロックゲーティング
次世代SpeedStep
(4)拡張されたデータ供給
消費電力のFSB(フロントサイドバス)
低消費電力の大容量L2キャッシュ
改良されたプリフェッチ
最初のムダなMicro-OPsの削減は先週のレポート「徹底してロスをなくすBaniasのアーキテクチャ」で説明した通り。次の、ムダな投機実行や分岐予測ミスの削減も、基本的にはMicro-OPs削減と同じ方向のアプローチだ。
今のPC向けCPUは、性能を上げるために、条件分岐命令の条件確定を待たずに処理を行なう「投機実行」を行なう。分岐の方向を予測して実行するわけだが、予測が外れた場合には、投機的に実行していた命令が全部ムダになってしまう。つまり、CPU内部の実行ユニットやデコーダ、スケジューラなどのリソースがムダに動作してしまうわけだ。その分、電力は余計に消費されることになる。このムダは、CPUのパイプラインが深ければ深いほど大きくなる。
Baniasでは、この投機実行のムダを省くために、投機実行をより最適化し、分岐予測をこれまで以上に強化する。分岐予測の強化については、IDFではJIT(Just In Time)コンパイラやオブジェクト指向言語への最適化や、様々なサイズのループの認識などが挙げられた。ようは、新しいソフトウェア形態に対応してゆこうというわけだ。
ただし、具体的な実装については、IDFではループ検出(loop detector)と間接分岐(indirect branch)専用のプレディクタ(predictor)の2つが加わるという以上の説明はなかった。新しい分岐予測手法を取り入れることはわかったが、まだその内容は明かされていないという状態だ。
 |
| Intel CPU ダイサイズ移行図 ※別ウィンドウで開きます |
●予測精度を上げるのはIntelの方向性
Intelの説明によると、Baniasではこうした分岐予測の強化によって、予測ミスが20%以上低減されるという。実際には分岐予測精度は現在のCPUでは多くのコードで90%以上に達しているので、20%以上削減されたとしても予測精度自体は2%以下しか向上しない。しかし、今のCPUはパイプラインが深くなっているため、1つの分岐ミスでロスするCPUリソースの消費は大きい。そのため、例え1-2%の向上であっても、かなり効果が大きいはずだ。
IDFでは、下の図のようにトータルの実行時間のうち、予測ミスからの復帰とデータミスのストールで半分近くを占めることが示された。予測ミスを20%減らせれば、この時間は大幅に削減できることになる。また、20%ミスを減らせば、それに見合う分だけムダなリソースの利用を減らし、電力消費は減るという論理だ。Baniasはもともと、Pentium 4のような深いパイプラインは持たないと見られるため、分岐ミス時のペナルティとロスもPentium 4と比べると小さいはずだ。
Intelは伝統的により複雑な分岐予測を採用して予測精度を上げようとする傾向がある(最初に2レベル分岐予測をインプリメントされたCPUはPentium Proだった)。Baniasもその流れを受け継いでいるようだ。これは、予測アルゴリズム自体はそれほど複雑にせず、予測できる範囲を上げることで性能を上げようとするAMDとは方向性が異なる。ちなみに、分岐予測強化に走るもう1つのPC系CPUメーカーは、意外かも知れないがCentaur Technology/VIA Technologiesだ。
分岐予測回路は、トレードオフがあり、この部分をあまり複雑にすると、予測に時間がかかるようになり、高クロック化のためには予測ステージ数を増やさなければならないといった問題が生じる。しかし、Baniasの場合は、もともとのフィロソフィが、高クロック化よりも効率の向上にあるので、分岐予測の強化は理にかなったアプローチとなる。
 |
 |
| IDFでの分岐予測に関する資料 | Intel CPU トランジスタ移行図 |
●他にも想定されるBaniasの強化ポイント
Baniasでは、先週紹介したMicro-OPs FusionやDedicated Stack Managerで合計15%のMicro-OPsを削減する。そして、分岐予測の向上などでムダな投機実行をさらに数20%減らす。CPUの世界で、このパーセンテージの効率向上はかなり大きい。もし、BaniasがP6系(Pentium III)系アーキテクチャより20%多くのMicro-OPsを実行できるなら、同クロックの他Pentium III-Mより、理論上は20%性能が上がるからだ。(Hyper-Threadingしない限り)P6よりさらに効率の悪いPentium 4-Mと比べれば、さらに性能/クロックは高いはずだ。
また、Baniasにはおそらくほかにも改良ポイントがあると思われる。まず予想されるのは命令デコーダだ。
x86命令のデコードは負担が大きくボトルネックになりやすい。実際、Pentium III(P6)系ではここが最大のボトルネックの1つになっていた。Baniasではデコーダの効率はかなり完全されているはずだ。というのは、内部パイプのMicro-OPsの効率を15%向上させた分、デコーダの効率をよくしてMicro-OPsの供給を増やさなければならないからだ。x86コード側から見れば、1クロック当たりより多くのx86命令がBaniasにデコードされ処理されて行くことになる。
Micro-OPs Fusionでやっていることを考えると、実行ユニットの構成と各ユニットへの命令発行のメカニズムにもかなり手が加えられることが予想される。前のレポートで紹介したAthlon系の力業的なアプローチ(AthlonはMicro-OPs Fusionと似たような手法を使っている)ではなく、あっと驚くようなトリックが隠されている可能性は高い。
●論理的な帰結として次はHyper-Threadingへと向かう
こうしたBaniasアーキテクチャからは、この先の展開もある程度予想ができる。Baniasのフィロソフィはパフォーマンス/電力効率の向上にある。そのため、Banias系CPUははクロックの向上よりも、IPC(instruction per cycle:1サイクルで実行できる命令数)の向上に力点を置いている。この方向へとCPUをさらに発展させるとすると、Banias後継CPUはさらに多くの命令を並列実行しなければならなくなる。
そのため、Baniasは近い将来、Hyper-Threadingを必ずインプリメントして来ると予想される。Hyper-Threadingは、別にデスクトップだけに適したアーキテクチャではないし、Pentium 4風アーキテクチャだけに有効というわけでもない。それどころか、Baniasの方向性に、Hyper-Threadingはぴったり合っている。というのは、そもそもHyper-ThreadingはCPUの効率を上げるための技術だからだ。
現在のスーパースカラアーキテクチャCPUでは、シングルスレッド(1つの命令ストリーム)の命令から、CPUが並列に処理できる命令を見つけだすのはもう限界に来ていると言われている。ところが、プロセス技術が進めば、同じ消費電力でも搭載できるトランジスタ数は増える。つまり、CPU内部のリソースを増やすことが可能になる。
そのため、もともと効率のいいBaniasが、2004年以降にCPUの内部リソースを増やし、さらにIPCを高めようとしたら、並列性の抽出が制約になってくる可能性が高い。そこで有効になるのは、2つ以上のスレッドから並列に実行できる命令を抽出できるHyper-Threadingアーキテクチャだ。逆を言えば、将来のBanias後継CPUの効率を上げるには、Hyper-Threadingで並列に実行できる命令をさらに増やさないと間に合わなくなると想像される。おそらく、こうした拡張は、90nm版Banias「Dothan(ドタンまたはドーサン)」ではなく、その先のアーキテクチャで行なわれると見られる。
また、メインメモリDRAMインターフェイスの統合も、将来のどこかの時点で行なう可能性もある。というのは、メモリアクセスレイテンシが、CPUの効率を劇的に悪化させているからだ。CPUを本当に効率的にしようと思ったら、DRAMインターフェイスは統合するのが筋が通っている。ただし、現在のようにIntelがDRAM業界を誘導できず、コモディティDRAM(汎用DRAM)の流れが予想できない現状では、この方法はリスキーなので、Intelが本当にそこまで踏み込むかどうかは不鮮明だ。
□関連記事
【9月13日】【海外】徹底してロスをなくすBaniasのアーキテクチャ
http://pc.watch.impress.co.jp/docs/2002/0913/kaigai02.htm
【9月12日】【海外】7,700万トランジスタを電力効率向上に費やす「Banias」
http://pc.watch.impress.co.jp/docs/2002/0912/kaigai01.htm
(2002年9月19日)
[Reported by 後藤 弘茂]