ロードマップでわかる！当世プロセッサー事情 第69回

スーパースカラーによる高速化とx86の問題点とは

　今回はちょっとパイプラインから離れて、「SuperScalar」(スーパースカラー/スーパースケーラとも呼ばれる)の話をご紹介したい。

スーパースカラーの基本とは

　スーパースカラーという語源は、もともとはスカラーとベクトルという2種類の命令の処理方式に起因する。スカラー型というのは、要するに「普通の」CPUデータ方式で、x86命令のほとんどがこれにあたる。強いて分類すれば「SISD」(Single Instruction Single Data)に相当するもので、原理的にはひとつの命令でひとつのデータを操作するものである(2つとか3つなどの場合もたまにはあるが)。

　これに対抗する概念がベクトル型で、身近な例で言えば、MMXから連なる「SIMD」(Single Instruction Multi Data)に分類されるものがそれにあたる。こちらはひとつの命令で複数個のデータを扱えるものを指す(MMXですら最大で同時に8つのデータ同士の演算で、16個のデータを扱える)。

　ではスーパースカラーは？　と言うと、スカラー型の流れを継承しつつ、同時に複数命令を実行できるようにすることで、結果的に複数個のデータも同時に扱えるようになる、というものである。

　典型的なスーパースカラーを搭載したCPUパイプラインは、図1に示すようなものとなる。ここでは3命令同時実行のケースである(煩雑になるのでラッチなどは省いた)。基本的には実行ユニットのみ複数になるが(この場合だと3命令分)、そのほかのユニットはひとつである。とはいえ、例えばFetchやDecodeは当然3命令分を一度に処理するような形になるし、Data Fetchも必要なら複数データの取り込みをまとめて行なう必要がある。Writebackも3命令分の結果を書き戻すことになるため、結構複雑にはなるが、それでも同じものを3つ用意するよりは、少ない回路規模で収まる。

図1 典型的なスーパースカラーのパイプライン

　こうしたスーパースカラーが理想的に動く場合、図1下側のように1サイクルあたり3命令での処理が可能になる。これはパイプライン段数を重ねて動作周波数を引き上げるよりも、はるかに効率的に処理できることになる。パイプライン段数が少なくても動作すれば、パイプラインハザードの影響も少ない。また動作周波数を下げられれば、相対的にパイプラインストールの影響も減る。メモリーやキャッシュなりへのアクセス時間は一定だが、動作周波数が下がれば相対的に待機するサイクル数が減るためだ。これらのメリットは大きい。

スーパースカラーの前に立ちふさがる
命令の依存関係の壁

　もちろん、実際にはこんな風にうまくいくことはまずない。スーパースカラーには「命令の依存関係」という壁が立ちふさがっているからだ。例えば、以下のような3つの命令があるとする。

• 命令1　R3＝R1＋R2
• 命令2　R6＝R4＋R5
• 命令3　R7＝R3＋R6

　命令1と命令2は同時に実行できる。というのは、命令1はレジスター1～3(R1～R3)、命令2はレジスター4～6(R4～R6)を使っているので、同時に実行しても害はないからだ。ところが、命令3はこの命令1と命令2の結果を利用しての計算となる。そのため、命令3は命令1と命令2が完了するまで実行できない。

　命令3が実行できるのは、最初の2つの命令のWritebackが完了し、その結果をData Fetchできるようになってからであり、そのために3サイクル遅らせてパイプラインに投入する必要がある。つまり、以下の図2に示すように、この場合だと7命令分のパイプラインがまるまる空いてしまうわけで、このままではさっぱり性能改善につながらないのがおわかりいただけよう(スーパースカラーを利用しない単なるパイプラインと同じ性能になってしまう)。

図2 命令3の待機によるパイプラインの空き