ソフトウェアパイプライン
ソフトウェアパイプライン（英: software pipelining なので正確には「パイプライン化」）は、コンピュータ・プログラムの最適化技法のひとつで、パイプライン化された（命令パイプラインの記事を参照）プロセッサの実行ユニットで効率良く実行できるように命令スケジューリングできるよう、プログラムを変形するという手法である。高度なコンパイラではコンパイラ最適化により行われることもあるが、一般にはしばしば、多数回繰り返されるが1回の処理内容がごくわずかなループ（画像処理や信号処理などには多い）について、手作業で、一種のアウト・オブ・オーダー実行のようなプログラムの書換え（ループの繰返しをまたいで、コードの順序を前後に入れ替えることが多い）を行う。アーキテクチャによっては、その仕様にソフトウェアパイプラインを特に意識した要素があるものもあり、特にインテルのIA-64アーキテクチャが著名である。
下記のようなループ例を考える。
この例では、codice_1, codice_2, codice_3, がそれぞれcodice_4を操作する命令であり、互いに依存関係がある。
すなわち codice_1 は codice_2 の開始前に完了している必要がある。例えば、codice_7 はメモリからレジスタにデータをロードし、codice_8がデータに算術演算を行い、codice_9がデータをメモリに書き戻す。しかし、それぞれが異なるcodice_4の値に対して依存がないと仮定すると、codice_11 は codice_12 が完了する前に開始することができる。ソフトウェアパイプラインを考えない場合には、コードは下記の順序で実行される。
各命令は完了に 3 クロックかかるとする（制御ループのコストを考えない）。また（現代的なシステムでは一般的だが)実行中の命令に対して依存関係がなければ命令を各サイクルで割り当てることができるものとする。パイプライン化しない場合には、各ループが7サイクル(3 + 3 + 1, codice_13 は codice_3 を待つ必要がないため)かかることになる。
ソフトウェアパイプラインによって下記のように命令列を並べ替えると、
毎サイクルで命令を割り当てることができ、全体が9サイクル、ループが平均 3 サイクルで実行できる。
一般にソフトウェアパイプライニングはループ展開と組み合わせることで、うまく実現できる。例えば上記の例は、下記のようにも記述することができる（codice_15 が 3 の倍数とする）
もちろん、繰り返し回数が展開する数で常に割り切れるとは限らない（この問題に対する解答は、ループ展開の項目を参照のこと)。なお、ソフトウェアパイプラインではこのような問題に対する効率的な解法である
Duff's device を利用できない点に注意が必要である。
一般的には、ループ展開がソフトウェアパイプラインの最適の実装方法でない場合もある。下のようにレイテンシが大きい命令を含むループを考えると、
命令 codice_9 のボトルネックを避けるためには、ループが 12 回以上回る必要がある。つまりループ部分のコードは12倍以上増加する(使用するメモリ量に影響するだけでなく、キャッシュ性能にも影響する。"参照")。さらに、codice_15 が 12 で割り切れない場合に追加するコードがループ自体より大きくなる可能性がある。このコードでは（これ以上をコードの膨張させずに）ソフトウェアパイプラインを使用できないために効率が悪くなる。また、codice_15 がループが展開されない場合のループ回数に対してコードサイズの点から適切であったとすると（例えば10-20程度)、実行時間の大半を、効率的でない12の余りの部分のコード実行に費やしてしまい、ソフトウェアパイプラインによる最適化が非効率なものになってしまう。
上記の例を異なる方法でソフトウェア実装したものを示す。（"前処理"と"後処理"については後述する）
ループの前後で実行する前処理・後処理について説明する前に、このコードが繰り返し部分について元のコードと同じ結果を得られるかを検証する。元のループで7度目の繰り返しを考える。パイプライン化されたループの最初の繰り返しでは、元のループでの7度目の繰り返しまでの命令を含んでいる。命令列は下記のようになる。
しかし、元のループとは異なり、パイプライン化されたものは、命令 codice_9 のボトルネックを回避できる。codice_20 およびその結果に依存した codice_21 の間には命令が12個あり、codice_20 のレイテンシが無駄にならずに他の命令の実行に使用される。
前処理と後処理では、繰り返しの始めと終わりを処理する。下記が前処理として考えられるコードである。
各行がパイプライン化されたループにおける一回分の繰り返しに相当し、繰り返し自体のための命令は取り除かれている。後処理も同様である。
前処理と後処理の必要性は、ソフトウェアパイプラインを実装する上で難しい点の一つである。例における前処理は18命令で、ループ自体の3倍も大きい。また後処理も18命令である。すなわち、前処理と後処理は合わせてループ自体より6倍大きい。この例ではまだループの展開を試みるほどではないが、ソフトウェアパイプラインは速度とメモリ使用量の点でトレードオフを必要とする。コードサイズが大きくなりすぎると、キャッシュの性能が相対的に下がるために実行速度に影響を与える。
さらに困難な点は、多くのアーキテクチャではほとんどの命令がレジスタを引数に用いており、特定のレジスタが命令にハードコードされている点である。つまり、多くのアーキテクチャでは、「レジスタcodice_23 の内容とレジスタcodice_24 の内容を乗算し、結果をレジスタcodice_25 に格納せよ」(codice_23, codice_24, codice_25 をレジスタやメモリから取得した数値とする)といった命令を使うことはできない。このことは従来のアーキテクチャ上ではソフトウェアパイプラインを効率的に実装できない理由としてしばしば取り上げられる。
ループ本体のコードにレジスタを割り当てる際、codice_32 の結果が2回のループの間ずっと生存させている必要がある。codice_32 の結果と codice_2 の入力に同じレジスタを用いると、誤った結果を生じる。
しかし、ループの本体を複製すると、問題が解決できる。
ここで命令 codice_32 と命令 codice_36 に異なるレジスタを割り当てることができる。詳細には
各命令が出力レジスタに書き込む前に入力レジスタを読み込むことが保証できれば、このコードは正しく動作する。複製されたループ本体コードの最初では、codice_37 が codice_32 の結果を保持している。codice_4 が2増加するので、これは複製されたループの繰り返し部分では codice_1 の値である。
もちろんコードの複製により前処理や後処理と同様コードサイズが増加し命令キャッシュへの圧迫が大きくなる。にもかかわらず、十分な命令レベルの並列化が可能なアーキテクチャで、ループの回数が大きい場合に適用すれば、コードサイズを増加させても十分価値がある高い性能を容易に発揮することができる。
インテルの IA-64 はこのようなソフトウェアパイプラインの困難な点を念頭に置いて設計されたアーキテクチャの一例である。ソフトウェアパイプラインに関係するアーキテクチャ上のポイントの主要なものとして、以下のような点などがある。