Skylakeの改良点を予想する~スケジューラ

前回はフロントエンドについて書いたので今日はスケジューラまわりを予想してみる。

 最近のIntelのメインストリームCPUは一貫して4 wayのRSを持っている。もともとはP6で導入された3 wayのRSがCore2で4 wayに拡張されたものである。P6系のマイクロアーキテクチャでは、すべての命令を単一のRSからすべての実行ポートにDisatchするマイクロアーキテクチャとなっている。これに対し、例えばAMDのK10までのマイクロアーキテクチャではひとつの実行ポートに対しそれぞれ1つのRSを持つ分散RSもある。分散RSの欠点は、uOpsをRSにIssueする時点で実行ポートが決定してしまうため、Dispatch時に実行ポートの融通ができなくなってしまうことである。一方で単一RSの欠点は実装コストである。n wayのRSは任意のnエントリを抜いて全体を詰めるデータ構造となっているが、この実装コストはO(n^3)である。このためway数の多いRSの実装は現実的でない。

この問題に対して、いくつかの手法が考え出されている。一つはRSのクラスタ化である。例えばn wayのRSをn/2 wayのRS2つに分割すれば実装コストは1/4ですむ。一方でRSの分割は分散RSと同じ欠点、実行ポートの無駄を発生させてしまう。そこで、そもそも異なる命令種(例えばGPとFP)をDispatchするポートを別RSに割り当てることが多い。AMDのBulldozerはRSをクラスタ化した例である(RSだけではないけど)。一方でIntelは単一RSを採用し続けている。なぜだろうか?その理由を推測してみる。

一つは、そのままだが、4wayのRSの実装コストを許容していることである。もう一つはMicro Ops FusionによりRSのway数を超えるuOpの同時Dispatchを可能としていることである。

Micro Ops Fusionとはなんだったのか

Micro Ops FusionはPentium Mで導入された技術だが、Intelから実装詳細について発表はなかったんではないかと思う。たぶん。そこで参考になるのが特許である。


Patent US20040034757 - Fusion of processor micro-operations - Google Patents

読むのがめんどくさいが、以下の図がもっともよく仕組みを示していると思う。メモリオペランド命令やストア命令は2uOpsであるが、RSの1エントリにopcode1とopcode2が含まれており、opcode1の実行準備ができ実行されると結果が書き戻され、さらにopcode2の実行準備ができるとDispatchされエントリが取り除かれる。SNB以降ではPRF化されているのでsrcはPRF番号になると思われる。

 http://patentimages.storage.googleapis.com/US20040034757A1/US20040034757A1-20040219-D00006.png

 肝は何かというと、たとえばメモリオペランド命令のloadとopはload後でないとopが実行できない。RSは命令順序によらず依存関係を解決するための仕組みであるので、あらかじめ依存関係がわかっているuOpsを別エントリにするのは無駄である。RSにとってMicro Ops Fusionの利点は二つある。一つは単純に消費エントリ数を削減できることである。ただしエントリ自体は大きくなる。もう一つは第一opをDispatchする際にはエントリの削除操作が必要ないことである。これによりRSのway数を超えるuOpの同時Dispatchを可能となる。

いいこと尽くめのようだが、Micro Ops Fusionはクラスタ化と組み合わせると効果が薄い。例えばGPとFPでスケジューラを分けた場合、FPのメモリオペランド命令はGPとFPのRSそれぞれに1uOpのエントリを必要としてしまう。

長くなったので続きはまた今度書こうかと思う。