性能が上がらないもうひとつの要因、つまりIPCの向上が10%程度という話の理由はデコーダ部がSandy Bridgeから殆ど変わっていないからだ。「殆ど」というのは今回追加された、AVX2やらTSXやらの新命令に対応は施されているという話で、逆に言うとSimple×3+Complex×1のDecoder構成は変わっていないし、Instruction Fetchも16Bytesから最大5つのx86命令をFetchという部分も変わっていない。
なので、普通にメモリからx86命令を取り込み、これをμOpに変換して処理という通常のケースでは、Decode部が律速段階になってしまい、基本的に性能に差はない。細かく言えば、Complex Decodeは最大4つのμOpを生成するので、Decode部全体では7μOp/Cycleが生成されるが、これはいわばピーク値であって、普通は5μOp/cycle程度と考えられるから、Executeの構成は完全にOverkillである。
ただSandy Bridge以降はこれ以外の状態がある。それはIn-Order部と並行する形で設けられるμOp Decoded Cacheから命令を取り込むケースだ。このケースでは、μOp Decoded Cacheは32Bytes/cycleの帯域でμOpを供給するから、1cycleあたりのμOp数は8を超える可能性が高い。キャッシュそのものも1500μOpの容量を持つから、かなりの規模の繰り返し処理はここにHitすると考えられ、このケースでは最大8つのExecute Unitがフルに活用されることになる。つまるところ、Haswellでは、
- μOp Decoded CacheにHitする
- Load/Storeを煩雑に行う
という2つのケースではSandy Bridgeよりも性能が上がることが予測できるが、その他のケースではSandy Bridgeとさして変わらない性能になると思われる。これを均すと平均10%程度の性能改善というのは、まぁ感覚的には十分納得できる数字である。
なんでこの程度の改善に留めたのか、というのは消費電力や回路規模の複雑さとのバランスをとったものと思われる。実のところμOps Decoded Cacheを搭載したことにより、Sandy Bridge世代では(μOps Decoded CacheがHitしている間は)命令供給にExecute Unitの処理が追いつかない位になっていた。今回はIn-flight命令数を増やすとともにExecute Unitの数を増やすことで性能のバランスを図ったというのが正しい見方に思えるし、この範囲だと消費電力の増加はそれほど問題にはならない。
というのは、μOps Decoded CacheがHitしている間はFetch/Decodeが停止しているからで、この2つがCPUの消費電力のかなりの部分を食っており、一方DispatchやExecute Unitの消費電力はたいした事ではない。だからExecute Unitの増加やDispatchの拡張で消費電力が若干増えても、処理できる性能を増やすことで性能/消費電力比は改善できるし、逆にμOps Decoded CacheがMissしているケースではSandy Bridge並のμOpしか供給されないから、新規に追加したExecute Unitは遊んでいることになる。
Netburst Architecutureの世代ではこの遊んでいるExecute Unitの消費電力も馬鹿にならなかったが、Nehalem以降ではClock Gatingに加えてPower Gatingも搭載して遊んでいるユニットの消費電力を極限まで落とすから、実際の消費電力増加分はほんの僅かでしかない。そんなわけでExecute Unitの追加は性能/消費電力比を高めるのには効果的と判断されたのであろう。
ここで、「んじゃいっそDecodeをもっと拡張したらどうなるか?」という仮定をちょっとしてみると、あまり上手くはいかなそうだ。例えばComplex Decode×1+Simple Decode×4とする。Fetchは今で「最大」5命令/cycleのx86命令Fetchを行えるが、これはあくまでもピーク値で、安定して5命令/cycleをFetchできるようにするためにはL1からの取り込みを32Bytes/cycleに増やす必要がある。まずここで消費電力が増える。次いでDecode段が単純に今の20%以上の消費電力が増える上、回路規模的にも結構大きくなる。Decode以降の各ステージも、現在のものよりも帯域を増やす必要があるだろうし、相対的にμOp Decoded Cacheのサイズや帯域ももう少し引き上げないとバランスが悪くなる。Execute Unitも果たして今の8つの構成で十分かは検討の必要があるだろう。
結果として、内部を壮絶に作り変える必要が出てきそうで、今回は間に合わないと判断したのだろう。実際IntelのArchitectもそれに類した発言をしており、今回は既存のDecoderのままEfficiencyを高める、という方向性になったようだ。ちなみに上の仮定も、そもそもComplex Decode×1+Simple Decode×4が良いのか、Complex Decode×2+Simple Decode×3が良いのか、という疑問があるわけで、Complex Decodeを増量するほうが柔軟性は増す気がするが、性能への寄与がどのくらいあるのかは疑問だし、回路規模は更に大きくなるだろう。
このところ、プロセス微細化によるトランジスタ増分はむしろGPU側に割り振られる傾向が強く、CPU側にはそれほどトランジスタのゆとりが無くなっている面もあり、大きくダイサイズを増やすような改造はしにくいとも言える。そんなわけで、もしDecode部に手を入れるとすれば、それは次のTockである14nm世代のSkylakeになるのではないかと思われる。
