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

CPU高速化の常套手段 パイプライン処理の基本 【その2】

CPUの性能発揮を阻害する「パイプラインストール」

　前回に続き、今回もCPUのパイプライン処理について解説する。前回の最後では、「パイプライン段数を無闇に増やしても問題」という話をした。理由のひとつは消費電力だが、これはまた別の話になるので、今回はもうひとつの理由である「パイプラインストール」と「パイプラインハザード」の方を取り上げてみたい。

　この2つは時々混同されることもあるが、基本的には別の要因で発生する問題であり、対応方法もちょっと異なる。まず前提として図1のようなケースを考えてみる。パイプライン段数は10段となっているため(昨今のx86プロセッサーから言えば短め)、例えば15個の命令を処理するのに要する時間は、合計24サイクルを要する計算だ。

図1 10段のパイプラインを持つCPUでの命令の流れ

　まずパイプラインストールだが、これはパイプラインが「止まる」(Stall)することを示す。よくありがちなのは、Data Fetchだ。これは要するにデータを取り込む処理である。

C＝A＋B

　例えば、命令3が上の命令「AとBを加算して、Cに結果を入れる」を実行する場合、加算に先立ってAとBの値を確定しなければならない。この値の格納にはCPU内部のレジスターが割り当てられることが多く、この場合は遅れが出ない。通常なら、内部レジスターは1サイクルでアクセスできるためだ。

　ところがレジスターの数は必ずしも多くないし、レジスターにすべてのデータが入っているとも限らない。どこかでメモリーにアクセスする必要がある。上の命令のケースでは、「Aはレジスターが使えるが、Bはメモリーから値を取得する必要がある」と想定しよう。するとどうなるか？　というのが、次の図2である。

図2 図1の処理中に命令3でメモリーアクセスが発生した場合

　7クロック目までは、順調にパイプラインの各ステージが動作する。ところが、7クロック目のData Fetchステージ(図中の黄色部分)でメモリーアクセスが発生すると、パイプラインはそのデータをメモリーから読み込むまで、待機することになる。図1を見直してもらうとわかるが、パイプラインの場合は「あるステージが待機すると、それ以後のステージも全部待機せざるをえない」という欠点がある。そのため命令3以降の処理は全部、メモリーアクセスから帰ってくるまで待機することになる。