「Skylake」完全攻略!!(追加検証) - 内部解析で第6世代Coreの謎に迫る

RightMark Memory Analyzer 3.8 - Instruction Decode(グラフ28～43)

cpu.rightmark.org
http://cpu.rightmark.org/

先日はプロバイダ代の支払いが滞ったせいかどうか知らないが、しばらくHost Unavailable状況に陥った(現在は復活)rightmark.org。Forumもアクセス不能になっており、rightmark.orgが再びアクセス不能になっても不思議ではないので、必要な方はいまのうちにダウンロードをしておいた方が良いと思う。

ここではあくまでSkylakeの内部構造を見るのが目的なので、Godavariは落としている。また、外部の影響を最小限にするため

EISTやTurboなど動作周波数変動を行う機構は全て無効化し、動作周波数は定格に設定(Haswell/Skylakeは4GHz、Broadwellは3.3GHz)
HyperThreadingは無効化
GeForce GTX 780を利用(内蔵GPUは無効化)

として実施している。

さて、まずはDecode Bandwidth(グラフ28～43)を見てみよう。まずここではっきりした事が3つある。

パイプラインのフロントエンド、つまりPrefetch～Decodeに相当する部分はSkylakeで強化された気配はない。年頭にこちらで「SkylakeではDecodeに手が入るのではないか」と予測したが、見事に外れたことになる。少なくともこの世代では、そうした形跡は見られず、引き続き4命令/cycleのDecodeとなる。
Decoded μOp Cacheに大幅に手が入ったか、もしくはパイプラインの外を大幅に強化した。
Decodeの中身にも手が入った可能性が高い。ただし、それは単純な意味での性能改善ではない。

まず1つ目、例えばグラフ28のNOPのピーク性能は4Bytes/cycleで、これを見る限りピーク性能は4 x86命令/cycleであると結論付けられる。これはさらに命令長の長いテストでも同じであり、Skylakeのピーク性能がHaswell/Broadwellを超える結果は出ていない事からも確認できる。

ではフロントエンドに全く変更がないのか? というのが2点目。デコード部そのものには変更はないが、Decoded μOps Cacheの容量、もしくはμOpsの持ち方が変わった様に見受けられる。これはグラフ28～33まで、SkylakeのBandwidthが常に4命令/cycleを維持できていることから想像される。

もともとDecoded μOps CacheはSandyBridgeの世代で導入されたもので、そのサイズは1500μOpsとなっている。これはBroadwellも同じで、例えばグラフ29を見るとHaswell/Broadwellは最初の2KB近くまでは8Bytes/cycleが維持されているが、その後急速に性能を落として6Bytes/cycleあたりになり、これが256KBあたりまで続く。これはL1およびL2の帯域が6Bytes/cycleになっていると思われる。

さて、問題はこの落ち込みを見せる場所が、実行する命令によって異なるということだ。これはDecoded μOps Cacheにどういう形で命令を格納するか次第という部分もあるのだろう。

SUB(グラフ29)、TEST(グラフ31)、CMP #1(グラフ33)などは2KBあたりからSkylakeとHaswell/Broadwellの傾向が全く変わるのに対し、NOP(グラフ28)やXOR(グラフ30)、XOR/ADD(グラフ32)ではL2 Missとなる256KBあたりまでほぼピークの性能が続く。これに対して、Skylakeではほぼ8MBあたりまで常に4命令/cycleが維持される形である。これは、Decoded μOps Cacheに大幅に手が入ったことを示唆している。

しかし、これだけでは説明がつかない場合もある。例えばグラフ34がそれに当たる。256KB、つまりL2 Hitの範囲までは16Bytes/cycleが維持されているが、その先は14Bytes/cycle弱まで帯域が落ちている。

またグラフ35以降で見ると、4命令/cycleが維持されるのはおおむね8KB程度までで、その後は次第に性能が低下して16Bytes/cycleまで落ち、256KBまでこれが維持されている。

これを考えると、L1/L2については16Bytes/cycleの帯域が維持される(これはHaswell/Broadwellも同じ)が、L3はHaswellで9Bytes/cycle程度、Broadwellで6Bytes/cycle程度なのに対し、Skylakeでは14Bytes/cycle程度が確保されていると思われる。要するにL2⇔L3間の帯域を大幅に増やした、というのが(Decoded μOps Cacheと同時に)行われた強化と思われる。

3つ目のポイントだが、まずグラフ42のPrefixed CMP #4にその一端が見えている。そもそもPrefixed CMPの場合、命令長は全部8bytesで

Prefixed CMP #1: <rep><addrovr>cmp eax, 0x00000000
Prefixed CMP #2: <rep><addrovr>cmp eax, 0x0000007F
Prefixed CMP #3: <rep><addrovr>cmp eax, 0x00007FFF
Prefixed CMP #4: <rep><addrovr>cmp eax, 0x7FFFFFFF

という命令が連続して与えられた時に、どれだけの処理速度で実行できるかという点から、Decode帯域を計算している。その前に行っているCMP #1～#6はとのPrefixが付いていない分、命令長は6Bytesになっており、要するに余分なPrefixが付くことでDecode帯域が落ち込んだりしないかを確認するためのものだ。

Prefixed CMP #1～#3(グラフ39～41)がいずれもピークで32Bytes/cycleなのに対し、Prefixed CMP #4のみSkylakeは28Bytes/cycle、つまり3.5命令/cycleに落ち込んでいる。ただし、逆にL2 Hitの領域では16Bytes/cycleを超える18Bytes/cycleの帯域があると見なされているあたり、この辺はまだDecoded μOps Cacheの管理下にある可能性もある。

それはともかくとしてピーク性能が28Bytes/cycleに落ち込んでいるあたりは、Prefixとの兼ね合いでは一部の処理をMicrocode送りにしている可能性がある。

この推定を補強するもう1つの結果が、グラフ43である。NOP命令の前にPrefixをバンバンつけてゆくとどこまで性能が落ちるか、というテストであるが、Haswell/Broadwellは最低で0.25命令/cycleまで落ちるものの、そこからは0.125Bytes/Prefix程度の傾きで帯域を増やしつつある。これに対しSkylakeでは極端に性能が低下したままである。Predixが14個の場合の帯域は0.11Bytes/cycleに過ぎず、このあたりからはPrefixが付いた場合の処理が相当遅くなっていることが伺える。

恐らくSkylakeの世代では、Prefixが付いている場合の処理は従来よりも遅くて良いと割り切ったのであろう。それが、単に新命令のサポートを今後追加するための準備(あるいは未公開の新命令の追加)で、既存のあまり使われない命令のサポートに費やすゲート数を削減したのか、あるいは高速化などのために遅くなりそうな部分をあっさり切り捨てたためなのかはここからは判断できない。