このページの本文へ

前へ 1 2 3 4 次へ

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

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

2010年09月13日 12時00分更新

文● 大原雄介(http://www.yusuke-ohara.com/)

  • この記事をはてなブックマークに追加
  • 本文印刷

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

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

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

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

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

C=A+B

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

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

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

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

前へ 1 2 3 4 次へ

この連載の記事

注目ニュース

ASCII倶楽部

最新記事

プレミアムPC試用レポート

ピックアップ

ASCII.jp RSS2.0 配信中

ASCII.jpメール デジタルMac/iPodマガジン