Raptor Lake ＆ Zen 4 Deep Dive - 現役2大アーキテクチャの深層を分析する

◆RMMA(グラフ137～222)

RMMA
Rightmark.org
http://cpu.rightmark.org/products/rmma.shtml

久々のRMMAである。こちらであるが今回は

Alder Lake ：Core i9-12900K P-Core
Raptor Lake：Core i9-13900K P-Core
Zen 3 ：Ryzen 9 5950X
Zen 4 ：Ryzen 7 7700X

の4つのデータをご紹介する。実はこのうちAlder LakeとZen 3に関しては、こちらのデータの再利用であり、今回Raptor LakeとZen 4のみ新規にデータを取得した格好になる。いずれもBIOS Setupで動作周波数を固定して実施している。またAlder LakeとRaptor LakeはE-Coreは無効化してP-Coreのみでテストしている(理由はAlder Lakeのテストの時と同じく)。

さて最初はDecode Bandwidth(グラフ137～151)。繰り返しになるが

である。

• グラフ137

• グラフ138

• グラフ139

• グラフ140

• グラフ141

• グラフ142

• グラフ143

• グラフ144

• グラフ145

• グラフ146

• グラフ147

• グラフ148

• グラフ149

• グラフ150

• グラフ151

さて、Zen 4コアはDecode段そのものはいじらずに、ただしMicroOp Cacheからの帯域を最大9 MicroOp/cycleに増強したのが変更点(逆にRaptor LakeはここはAlder Lakeから一切変更なし)な訳だが、NOP(グラフ137)ではなんとZen 4がピークで12命令/cycleと言うすさまじい数字を叩き出した。もっともNOPだからそもそもALUが動く必要は一切なく、Scheduler段で処理が終わる内容ではあるのだが、それにしても12命令/cycleは驚異的である。恐らくであるが、まずMicroOp CacheでNOPに関しては多重化(1つのMicroOpで複数のNOPを表現)が可能になっていると思われる。そうでなければ9 MicroOp/CycleというZen 4のMicroOp Cacheの帯域に引っかかるからだ。そしてZen 4のMicroOp Cacheの容量は6912で、これで10KB辺りまでこの12 Op/Cycleが維持できているという事は、恐らく1つのMicroOpで2つのNOPを表現できるような改良が施された、と考えるのが妥当かと思う。逆に言えばMicroOp Cacheの効果が切れると後はZen 3と大して変わらず、すると元々の4命令/Cycleというデコード帯域に落ち着くのは妥当なところ。ただNOPに関してはそんな訳で最大14K命令近くまで格納できるわけで、これがZen 3との大きな差になる格好だ。一方のAlder Lake/Raptor Lakeはピークの6命令/cycle近くを長期間維持できる事を示している。

もう少し意味があるところでSUBとかXORに関しては、MicroOp Cacheが効いている範囲ではZen 3/4とAlder Lake/Raptor Lakeが同等だが、その先はDecoderの性能そのままという形。しかしTESTではMicroOp Cacheの効果が薄く、Decode性能そのままになっている。

もう少し複雑なXOR/ADDだと、2つのALUが動く形になるため、効率はもう少し落ちる事になる。ただMicroOp Cacheが効く範囲で言えばZen 3/4はAlder Lake/Raptor Lakeを凌いでおり、Zen 4ではZen 3よりもその範囲が広がっている。これは続くCMP #1～#6でも同じだが、レジスタ指定でなく即値が入るとMicroOp Cacheでカバー出来ないようで、#2～#6ではMicroOp Cacheの効果が見られないのはまぁ仕方ないところだろう。これはPrefixでrepを重ねたPrefixed CMP #1～#4も同じで、やはりMicroOp Cacheの効果はない。なのでもう素直にZen 3/4は4命令/cycle、Alder Lake/Raptor Lakeは5命令/cycleに収束している。結果から言えば、Alder LakeとRaptor LakeはDecode段には差異は一切なし。Zen 4はMicroOp Cacheが広帯域化&大容量化した以外はZen 3と差は見られず、ということになる。

• グラフ152

ついでにDecode Efficiency(グラフ152)。こちらはNOP=0の場合を除くとEfficiencyはAlder Lake/Raptor LakeとZen 3/Zen 4の2グループにきっちり分かれ、差異はない。

• グラフ153

• グラフ154

• グラフ155

• グラフ156

意外に差異が大きかったのがI-ROB(グラフ153～156)。Alder LakeとRaptor Lakeは基本同じで、ただ命令数が少ない時のLatencyがRaptor Lakeの方がやや低いという、正常進化というか若干の改良が施された程度で、ほぼZen 3に比肩する構成だが、Zen 4は全く異なるアルゴリズムになっている。On-the-fly状態の命令数が少ない時には効率が悪いが、命令数が増えても悪化しないという意味では、Desktop/Mobile向けというよりはServer向けという感じではあるが、発想そのものは悪くない。ただForward/BackwardはともかくPseudo-Random/Randomになると一気に悪化する辺りは、シナリオ次第とは言えどうだろう？ という気はするが。

• グラフ157

• グラフ158

• グラフ159

グラフ157～159はCache Bandwidthである。ReadのピークはAlder Lake/Raptor Lakeの方が高い(実際にはAVX512を使えばもっと上がる筈)が、これはAVX512の為にAGU周りを激しく強化しているからで、普通のアプリケーションでここまで使いきれるかはちょっと疑問である。それより面白いのがZen 4コアで、Zen 3と比べてL2の帯域が28Bytes/cycle→32Bytes/cycleに増えているし、L3での帯域も上がっているあたりは、地味に強化ポイントと言える。WriteはZen 3/Zen 4はほぼ同じだが、なぜかRaptor LakeはAlder Lakeと比べてL2領域での帯域が下がっている。容量が増えた以外の違いは無い筈なのだが、容量が増えた事の副作用だろうか？ CopyはReadとWriteの低い方で律速される形だから、傾向としては別におかしくない。

• グラフ160

• グラフ161

• グラフ162

• グラフ163

グラフ160～163がD-Cache/RAM Latencyだが、これは先ほどSandraでも確認した話で、これが再現された形になる。Memory Accessの領域ではZen 3が比較的優秀だが、これは唯一DDR4を使っているからで、DDR5を利用するその他の製品のLatencyがやや大きくなるのはまぁ仕方がない。

• グラフ164

• グラフ165

• グラフ166

• グラフ167

• グラフ168

• グラフ169

グラフ164～169がL1/L2 D-Cache Associativityの確認である。L2はUnifiedなのでアレだが、D-L1経由とI-L1経由での性能差の確認の為におこなった。先に結果を書いておけば

となっている。まずはD-L1(グラフ164～166)で、Zen 3/Zen 4はきちんとSegment=8までは低めながら、その先は増加しているのに対し、Alder Lake/Raptor Lakeはもう少し手前(Segment=6)以降はLatencyが悪化する傾向が見えているのはちょっと不思議である。しかもRaptor Lakeの方が最終的なLatencyが増えるのは、L2を増強した反動だろうか？

一方D-L2(グラフ167～169)の方だが、Alder Lakeは12-way、Raptor Lakeが16wayという数値が正しい事はグラフからも読み取れる。ただSegment=13なり17から急に増えるのではなく、3段階で徐々にLatencyが増える形になっているのはちょっと不思議である。一方Zen 3/Zen 4はこの部分では両者の間に差が見られない。9 segment以降のLatencyもそこまで増えないあたりは実装の巧みさの効用だろうか？

• グラフ170

• グラフ171

• グラフ172

• グラフ173

• グラフ174

• グラフ175

• グラフ176

• グラフ177

次がI-Cache Latency(グラフ170～177)。Near/Far共に、L2までの範囲で言えばZen 3とZen 4の間に差はなく、Alder Lake/Raptor Lakeに比べて低いLatencyを確保している。気になるのは、Random以外でZen 4が10MBを超えると急にLatencyが増える事だろうか？ まだL3の範囲に収まっているだけに、どうしてこうなるのかちょっと疑問である。同種の事はSandraでは観測できなかったので、RMMA側の問題な気もするが。

• グラフ178

• グラフ179

• グラフ180

次がTLB周り。こちらも先にスペックを書いておくと

となっている。

これを踏まえてまずD-Cache Size(グラフ178～180)を見ると、微妙に数字は合わないにせよ、Alder Lake/Raptor Lakeはまぁエントリ数に見合った傾向でLatencyが増えている。謎なのはZen 3/Zen 4で、64/72 EntryまではFully Associativityだから4cycleで一定なのはともかく、何でそこから512 EntryまでLatencyが増え、その先で戻るのかがいまいち判らない。別にI-TLBに引きずられる訳でも無いとは思うのだが。

• グラフ181

• グラフ182

• グラフ183

• グラフ184

• グラフ185

• グラフ186

• グラフ187

• グラフ188

• グラフ189

• グラフ190

• グラフ191

• グラフ192

グラフ181～192はAssociativityの確認である。Alder Lake/Raptor Lakeは相変わらず7 Entry以降から急にLatencyが増える謎の現象になっているが、ある意味理解できる。謎なのがやはりZen 3/Zen 4で、64 Entriesまでは安定しているのに128 Entriesで急に暴れ出すというのは(Zen/Zen 2の頃からそうだったが)もうAMDのプロセッサの特徴なのかもしれない。

• グラフ193

• グラフ194

• グラフ195

• グラフ196

• グラフ197

• グラフ198

グラフ193～198はI-TLB Sizeである。Alder Lake/Raptor LakeがL2 TLBがUnified構成な関係で結構急速にLatencyが増えるのに対し、Zen 3/Zen 4はL2 TLBも別々に設けられているためもあってか、Latencyそのものは増えるにしても安定しているのが特徴的である。ただサイズそのものが謎なのはD-TLBの場合と同じだ。

• グラフ199

• グラフ200

• グラフ201

• グラフ202

• グラフ203

• グラフ204

• グラフ205

• グラフ206

• グラフ207

• グラフ208

• グラフ209

• グラフ210

• グラフ211

• グラフ212

• グラフ213

• グラフ214

• グラフ215

• グラフ216

• グラフ217

• グラフ218

• グラフ219

• グラフ220

• グラフ221

• グラフ222

グラフ199～222がI-TLB Associativityである。傾向はD-TLBに近いが、相違点としては128 EntriesになるとAlder Lake/Raptor Lakeも結構暴れ、しかもLatencyがZen 3/Zen 4より大きくなることだろうか。とにかくことI-TLBに関しては、どんなアクセスパターンでもZen 3/Zen 4がAlder Lake/Raptor Lakeより優秀な事は確認できた。