CPU・命令サイクル・パイプライン

CPUは毎秒何十億回も動作する、と聞いても、1クロックに一つのプログラムが終わるわけではありません。プログラムを命令に分け、その命令をさらに複数の処理に分けて進めます。速さを考えるには、命令一つの所要時間と、一定時間に処理できる命令数を分けて見る必要があります。

命令が結果になるまで

典型的な説明用のCPUでは、命令の取込み、解読とレジスタ読取り、演算、必要に応じたメモリアクセス、レジスタへの書戻し、という流れを考えます。取込みではプログラムカウンタが示す場所から命令を読み、解読ではどの演算と値を使うかを決めます。

例えば加算命令なら、レジスタから二つの値を取り出してALUへ渡し、結果を指定のレジスタへ戻します。ロード命令では、ALUでアドレスを計算した後にメモリを読みます。分岐命令では、条件を調べた結果が次の命令の位置に影響します。命令によって使う回路が違います。

各段に1nsかかる5段の処理を考えます。1命令ずつ最初から最後まで処理すると、100命令には500nsかかります。各段の間にレジスタを置き、違う命令を同時に別の段へ流せば、理想条件では最初の命令が5nsで終わり、その後は1nsごとに次の命令が終わります。100命令なら104nsです。

理想的な5段パイプライン、各段1nsの場合
N命令の時間 = (5 + N - 1) × 1ns
100命令 = 104ns

1命令の所要時間は約5ns
流れが埋まった後の完了間隔は約1ns

この計算は段の時間が等しく、待ちも分岐のやり直しもなく、段間レジスタの費用も無視した例です。現実には一番遅い段や段間の費用がクロック周期を制約します。段数を増やすだけで、性能が段数倍になるとは限りません。

add t0, a0, a1
sub t1, t0, a2

2行目は、1行目が作るt0を必要とします。書戻しが終わる前に古いt0を読むと答えが違ってしまいます。こうしたデータ依存が処理時点の衝突を起こすと、データハザードになります。必要な結果が演算段ですでに得られていれば、レジスタへの書戻しを待たずに次の演算へ渡すフォワーディングを使えます。

ロードの直後に読んだ値を使う場合、値がメモリアクセス段の終わりまで届かないことがあります。説明用の5段構成では、フォワーディングを備えていても1サイクルの待ちが必要です。どの命令が何サイクル待つかは、具体的な回路とメモリの応答に依存します。

条件分岐では、条件の判定前に次の取込み先を確定できない場合があります。待つ方法もあれば、分岐予測に従って先へ進める方法もあります。予測が外れたら、誤った経路の処理を破棄し、正しい経路からやり直します。実行結果を確定する仕組みが、プログラムから見た正しさを守ります。

一つのメモリ用の入口を命令の取込みとデータの読書きが同時に欲しがる、といった資源の不足は構造ハザードです。命令用とデータ用の入口を分けるなど、回路の構成によって避けられる場合があります。ハザードはプログラムの誤りではなく、同時に進めるときに調整が必要になる状況です。

CPU時間は、実行命令数×平均CPI×クロック周期として考えられます。CPIは命令あたりの平均サイクル数です。命令数が同じでも、キャッシュミスや分岐のやり直しが増えればCPIが上がります。周波数だけの比較では、この待ち時間を見落とします。

近年のCPUには複数命令の同時発行やアウトオブオーダー実行などもあります。5段モデルは、すべてのCPUの実装図ではありません。依存と資源と分岐の三つから、処理が止まる理由を説明するための出発点です。

問1：パイプライン化すると1命令が必ず5倍速くなるでしょうか。なりません。主に改善するのは、複数命令が続くときの処理量です。

問2：命令数100万、平均CPIが2、周期0.5nsならCPU時間はいくらでしょうか。100万×2×0.5ns＝1msです。待ちを減らしてCPIを1.5にできれば、同じ周期でも0.75msになります。

メモリ待ちが起きる理由は、キャッシュとメモリ階層へ進んで確かめます。