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番号になると思われる。
肝は何かというと、たとえばメモリオペランド命令の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のエントリを必要としてしまう。
長くなったので続きはまた今度書こうかと思う。