命令パイプライン

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索
RISCマシンの基本的な5段のパイプライン(IF = 命令フェッチ、ID = 命令デコード、EX = 実行、MEM = メモリアクセス、WB = レジスタ・ライトバック)。縦軸は逐次的な命令列、横軸は時間。緑の列は、最初の命令がWB段にあり、最後の命令がフェッチされている時点を表している。

命令パイプライン: Instruction pipeline)は、コンピュータなどのデジタル電子機器で命令スループット(単位時間当たりに実行できる命令数)を向上させる設計技法の1つで、命令レベルの並列性を高める1技法。

命令パイプラインのあるプロセッサは、命令の処理を独立して実行できる工程(ステージ)に分割する。各工程は、前の工程の出力を自身の入力とし、自身の出力を次の工程の入力とするように相互接続されている。このような構成で各行程を並列化し、全体としての処理時間を大幅に削減する。

概要[編集]

基本的な考え方は、コンピュータの命令の処理を一連の独立した工程に分割し、各工程の処理結果を記憶するように構成することである。そうすることで、コンピュータの制御装置は最も時間のかかる工程を基準として命令を演算装置に送り込めるようになり、全工程を一体として処理するよりも高速化できる。パイプラインとは、各工程が同時にデータを運んでいて、各工程が次の工程をパイプのように接続されていることを意味する。

命令パイプラインの起源は、ILLIAC II プロジェクトか IBM Stretch プロジェクトと言われている。IBM Stretch プロジェクトでは、「フェッチ (fetch)」、「デコード (decode)」、「実行 (execute)」という用語が生まれ、それが一般化した。

最近のCPUは、クロック信号で駆動される。CPU内部には論理回路とメモリ(フリップフロップ)がある。クロック信号が入っていくると、フリップフロップが新たな値を受け付け、論理回路でその新たな値のデコードにある程度の時間がかかる。次のクロックパルスが入ってくると、フリップフロップはまた新たな値を受け付け、同様に処理される。論理回路を小さな部分に分割し、それぞれの間にフリップフロップを挟むようにすると、各論理回路が結果を出すのにかかる時間を削減できる。そうすることで、クロック周期も縮小することができる。例えば、RISCのパイプラインは次の5段階に分割されていて、それぞれの間にフリップフロップがある。

  1. 命令フェッチ
  2. 命令デコードとレジスタフェッチ
  3. 実行
  4. メモリアクセス
  5. レジスタへのライトバック

プログラマやコンパイラアセンブリ言語コードを書くとき、前提として命令は書かれた順序通りに逐次的に実行されるものとしている。つまり、ある命令が完了してから次の命令が実行されると仮定している。この仮定は命令パイプラインがある場合は正しくない。このことでプログラムの動作が不正になる場合、そのような状況をパイプラインハザードと呼ぶ。ハザードに対処する方法は様々なものがある。

パイプラインを使わないアーキテクチャでは、CPUの一部が命令を処理している間、他の部分が何もしていないことになり、効率が悪い。命令パイプラインはそのような何もしていない時間やCPUの部分を完全に無くすことはできないが、各部分が同時並列で動作できるようにすることで、プログラムの実行を大幅に高速化する。

だが、全ての命令が前後の命令と独立しているわけではない。単純な命令パイプラインでも、命令の完了までには5段階を要する。最高性能を発揮するには、ある命令が完了しようとしているときに、後続の4つの命令を処理している必要がある。後続の4命令が先頭の命令の結果に依存している場合、パイプライン制御回路は依存関係が解決されるまでパイプラインにストールを挿入したり、クロックサイクルを無駄にさせる必要がある。幸い、フォワーディングなどの技法でストールさせる必要性を大幅に削減できる。1命令の処理にかかる時間が同じ場合、命令パイプラインのあるプロセッサとないプロセッサでは(クロック周波数を段数に応じて向上させられるとして)、理論上はパイプラインの段数倍の性能の違いがある。実際には、ほとんどのコードは理想的な実行ができない。

命令パイプラインは1つの命令の完了までの時間を短縮するのではなく、同時に処理する命令数を増やすことで、命令の完了と命令の完了の間の遅延を短縮しスループットを改善する。パイプラインのステージ数(段数)を増やせば、同時に処理する命令数が増え、命令の完了と完了の間の遅延時間も短くできる。現在生産されているマイクロプロセッサは最低でも2ステージのパイプラインになっている(Atmel AVRPIC は2段のパイプラインである)。Intel Pentium 4 プロセッサは20ステージのパイプラインになっている。

長所と短所[編集]

パイプラインはあらゆる状況で有利というわけではなく、短所もある。

パイプラインの長所は次の通りである。

  • プロセッサのサイクル時間を短縮でき、多くの場合で命令処理レートを向上させる。
  • 加算器乗算器などの組み合わせ論理回路は回路規模が大きいほど高速化できる。代わりにパイプラインを使うと、回路規模は小さいままで高速化できる。

パイプラインの短所は次の通りである。

  • ハザードが発生するためコストがかかる。パイプラインのないプロセッサは一度に1つの命令しか実行できないため、ハザードが発生せず、制御を単純化でき、安価に製造できる。
  • 命令レイテンシ(1命令の実行にかかる時間)がパイプラインがない場合に比べて若干長くなる。これは、パイプラインが各段の間にフリップフロップを挟んでいるためである。
  • パイプラインのないプロセッサに比べて性能が予測しにくい。命令パイプラインのあるプロセッサはプログラム(命令の並び方)によって性能がばらつくためである。

[編集]

汎用パイプライン[編集]

一般的な4段のパイプライン。色つきの四角は命令を表しており、同じ色は同じ命令であることを示す。

右図は、一般化した次のような4段のパイプラインを示している。

  1. フェッチ (Fetch)
  2. デコード (Decode)
  3. 実行 (Execute)
  4. ライトバック (Write-back)

図の上にある灰色の矩形には実行を待っている命令が並んでいる。下の灰色の矩形には実行が完了した命令が並んでいる。真ん中の矩形がパイプラインを表している。

実行は次のようになる。

時間(クロック) 実行内容
0 4つの命令が実行されるのを待っている。
1
  • 緑の命令をメモリからフェッチする。
2
  • 緑の命令をデコードする。
  • 紫の命令をメモリからフェッチする。
3
  • 緑の命令を実行する(実際の命令処理を行う)
  • 紫の命令をデコードする。
  • 青の命令をフェッチする。
4
  • 緑の命令の結果をレジスタファイルかメモリに書き込む。
  • 紫の命令を実行する。
  • 青の命令をデコードする。
  • 赤の命令をフェッチする。
5
  • 緑の命令は完了した。
  • 紫の命令の結果を書き込む。
  • 青の命令を実行する。
  • 赤の命令をデコードする。
6
  • 紫の命令は完了した。
  • 青の命令の結果を書き込む。
  • 赤の命令を実行する。
7
  • 青の命令は完了した。
  • 赤の命令の結果を書き込む。
8
  • 赤の命令は完了した。
9 全命令を実行した。

バブル[編集]

周期 (Cycle) 3 で生じたバブルが実行を遅延させる。

実行中に何らかの中断が発生すると、パイプラインに「バブル (bubble)」と呼ばれる何もしない部分が生じる。右の図では、サイクル2で紫の命令のフェッチに遅延が生じ、サイクル3のデコードステージにバブルが生じている。紫より後の命令は全て1クロックサイクルだけ遅延するが、紫の命令より前の命令は普通に処理が続行される。

上の図と比べると、バブルが生じたことによって実行にかかるクロックサイクル数が7から8に増えている。

バブルはストールと似ており、各ステージでは何もしない。ただし、NOP命令をバブルの部分に挟むとバブルを消すことができる。

具体例[編集]

概念を明確化するため、3ステージの理論的なパイプラインを想定する。

ステージ 意味
Load 命令をメモリから読み込む。
Execute 命令を実行する。
Store 結果をメモリやレジスタに格納する。

そして、アセンブリ言語の以下のような擬似コードを実行する。

LOAD #40, A ; 40 を A にロード
MOVE A, B ; A を B にコピー
ADD #20, B ; 20 を B に加算
STORE B, 0x300 ; B をメモリセル 0x300 に格納

以下にその実行過程を示す。

クロック 1
Load Execute Store
LOAD    

LOAD 命令がメモリからフェッチされる。

クロック 2
Load Execute Store
MOVE LOAD  

LOAD命令を実行し、同時にMOVE命令をメモリからフェッチする。

クロック 3
Load Execute Store
ADD MOVE LOAD

LOAD命令はStoreステージにあり、その結果(40という数値)はレジスタAに格納される。同時にMOVE命令が実行されようとしている。AからBに内容を移す命令であるため、直前のLOAD命令の完了を待つ必要がある。このときフォワーディングという技法を使う。すなわち、LOAD命令でAに格納すべき値はExecuteステージで既に求められ、ステージ間のフリップフロップにある。そこでMOVE命令はExecuteステージの入力として前の命令のExecuteステージの結果を直接利用する。これがフォワーディングである。

クロック 4
Load Execute Store
STORE ADD MOVE

STORE命令がロードされ、MOVE命令は完了するところで、ADD命令を計算中である。ADD命令も同様にフォワーディングによって前の命令のExecuteステージの結果を利用する。

このように続いていく。この例でも明らかなように、命令には別の命令の結果に依存しているものがある。複数の命令がオペランドとしてある位置(メモリ、レジスタ)を参照している場合、それが入力であれ出力であれ、プログラム上の順序と異なる順序で実行すると、上述のようにハザードが発生する。ハザードが発生するのを防ぐ技法や、発生したハザードに対処する技法がいくつか確立されている。

複雑化[編集]

プロセッサの命令パイプラインは以下のような長さがある。

パイプラインが長くなると、プログラム上の分岐が発生したときに不利であり、パイプライン全体をフラッシュする必要があるが、分岐予測によってある程度対処できる。分岐予測が不十分であれば、状況は悪化する。高性能計算などの特定分野では、滅多に分岐しないプログラムを書くことができ、パイプラインが長いほど性能向上が期待できる。分岐が頻繁に発生する場合、最も分岐しそうな方向の命令をパイプラインに供給することで、分岐予測の失敗によるパイプラインのフラッシュで生じる性能損失を低減できる。gcov などを使ってコード網羅率を分析する技法により、個々の条件分岐がどういう頻度で分岐するかを調べることができるが、そのような分析は最適化の最後の手段である。

実行コードに多数の条件分岐命令があると、パイプラインによるスループット向上は望めない。プロセッサが次に実行すべき命令を知ることができないため、条件分岐命令を実行して分岐先が決まるまで、パイプラインは空(バブル)になる。分岐先の計算が完了すると、次に実行すべき命令が決まり、パイプラインが再び機能するようになる。極端な場合、パイプラインの1ステージ以外全てのステージが空(バブル)になるなら、パイプラインのないプロセッサと性能に大差ない状況になり、むしろパイプラインのないプロセッサよりも性能は低下する(ステージ間のオーバーヘッドがあるため)。

命令パイプラインでは、プロセッサが読み込んだ命令は即座に実行されるわけではない。そのため、その時点のプログラムカウンタに非常に近い命令を書き換えても、既にその命令がプロセッサ内に取り込まれていて、効果を発揮しないことがある。キャッシュメモリがこの現象をさらに悪化させる。ただし、これが問題になるのは自己書き換えコードだけである。

歴史[編集]

1961年IBM 7030(Stretch)は、マイクロプログラム方式でパイプラインと分岐予測を使用している[2]。以後のメインフレームの大半でも使用されている。

1970年代後半に、ベクトル計算機やアレイプロセッサなどのマスプロセッシング(スーパーコンピューティング)が始まった。非常に巨大なスーパーコンピューティング用のマシンでは、特別な設備やコア冷却を必要とした。初期の代表的なスーパーコンピュータにはCDC社の CDC 6600CDC 7600 があるが、その中心的な設計者のシーモア・クレイは後に CDC を辞めてクレイ社を設立した。クレイは X-MP 系列のスーパーコンピュータを開発し、乗算と加減算の両方にパイプラインを使用した。後に Star Technologies 社がパイプラインを別レベルの並列処理に使用した。これはいくつかのパイプライン化された機能が並列的に稼働するもので、同社技術者の Roger Chen が開発した。

現在ではパイプラインは、スーパーコンピュータやメインフレームの他、組み込み用を含めた大多数のマイクロプロセッサでも使われている。

関連項目[編集]

脚注[編集]

  1. ^ Best Extrime Processor: Xelerated X10q at Microprocessor Report
  2. ^ IBM Stretch (7030) -- Aggressive Uniprocessor Parallelism

外部リンク[編集]