Out-of-Order部(1)

さて、次はScheduler段である。On-the-flyで処理できる命令数が大幅に増え、これにあわせてLoad/Store Bufferなども大幅に強化された、という話は塩田氏のレポートにある通りだが、もう一つ大きいのはPRF(Physical Register File)を実装したという話である(Photo09)。別にPhysicalという名前が付いているから、では従来のRegister FileはVirtualなのか? というとそういう話ではない。

Photo09: このプレゼンテーションは塩田氏の方にもある。PRFは、こと性能面に関して言えば、むしろネガティブな可能性があるのだが、消費電力の観点では賢明である。最近だと、AMDのBobcatがやはり同様に物理レジスタファイルを採用していることで話題になった。

図1はNehalemまでの世代の一般的な構成を簡単な模式図にしたものだ。ここでは「まず何かしらのLoad命令が実行され、その結果をつかって演算を行なう」というシーケンスを考える。

図1

さて、このシーケンスでは、

(1) 最初のLoad命令が実行され、メモリからデータを取り込む。取り込んだ結果はとりあえずLoad Unitの内部バッファCに蓄えられる(①)。
(2) Load命令の完了に伴い、取り込んだ結果をRetirement Unitに戻す。この際内部バッファCからRegister File Aに値をコピーする(②)。
(3) 次の命令が実行される場合、Schedulerで実行タイミングが確定した段階で、Execute Unitの内部バッファBにその値をコピーする(③)。
(4) Execute Unitはその値を元に演算を行ない、必要ならばBに書き戻す(④)。
(5) 実行が終わると結果は再びRetirement Unitに戻される。このタイミングで内部バッファBからRegister File Aに値をコピーする(⑤)。

というわけで、少なくとも3回ほど「バッファ→バッファのデータコピー」が行なわれているわけだ。これが問題になるのは、そもそもデータの移動にコスト(＝消費電力)が掛かっており、またコピーの速度(＝所要時間)も問題になるからだ。特にSandy Bridgeからは従来の128bitのSSEレジスタを256bitのAVXレジスタに拡張しており、そろそろ消費電力や速度が無視できないものになってきた、というものだ。

ではSandy Bridgeではこれをどう解決したのか? というのが図2である。

図2

こちらの場合、処理の流れは、

(1) Allocateでは最初のLoad命令用に割り当てたRegisterのPointerを設定(①)。
(2) Load UnitはまずPointerをアクセスして(②)、Register Aを確定。その後Loadを実行し、Register Aに値を格納する(③)。
(3) 次の命令にあわせてAllocateはポインタを更新(④)。
(4) 演算命令もまずPointerをアクセスして(⑤)、Register Aを確定。その後値を取り込んで(⑥)演算を行ない、必要ならば書き戻す。(⑦)

となる。Pointerへのアクセスは発生するが、Register間のデータコピーが不要になっているのがお判りいただけようか。

では「なんで今までやらなかったのか?」という答えも、やはり図1と図2に示されている。まずはRegister AccessのLatencyである。図1の場合、必要とするユニット(図1の例で言えばAllocateとExecute、Memory Control)の物理的にすぐそばにバッファ(というか、Register)が置かれていた。Register Fileそのものは結構多いから、Aに相当するものは100以上のエントリを持つが、BとかCに関しては1ないし2エントリあれば足りるから、物理的に近接した場所に設けられるし、従ってアクセスのLatencyは非常に少ない。ところが図2の方式だと、物理的に離れた箇所に置かれるから、配線による遅延が馬鹿にならないし、配線そのものも複雑になる(その意味では、32nmプロセスのお陰でダイサイズが小さくなり、相対的に配線長が短くなったからこれが実現できた、という可能性も否定できない)。もう一つは、毎回ポインタを参照しないとアクセスができないという、いわば間接アドレッシングみたいな仕組みになってしまい、これによるレイテンシ増加が発生しやすいことだ。最終的にはこの間接アドレッシングによるアクセスペナルティは0になっていると思われるが(でないと性能面へのインパクトが大きすぎる)、これを実現するためにはそれなりの苦労があったと思われる。

実際この「Register Fileを一箇所にまとめる」というアイディアそのものはSandy Bridgeより前に実装したものがあるが、いずれも低消費電力向けの製品で、動作周波数もずっと控えめであった。2GHzを超えるプロセッサでこうした仕組みを実装しようとすると、このレイテンシ増加の対策のために高速動作回路や高速動作トランジスタを使わざるを得ず、これによる消費電力増加でRegisterコピー削減の効果が帳消しになってしまいかねないというのがこれまでの一般的な見解であり、こうした見解を覆してこの方式を実装したSandy Bridgeは、この一点だけでも賞賛されるべきかもしれない。

ということで長くなったので、以下は2本目のレポートに分けたいと思う。