Ryzen 9 9950X & Ryzen 9 9900Xを試す - Ryzen 9000シリーズ全モデルでZen 5を改めて詳細評価

◆RMMT 1.1(グラフ107～108)

グラフ107

今回はRMMAもあるので、その前段階のデータとしてRMMTの結果を。前回と同じで3D V-Cache搭載のRyzen 7 7800X3Dが入っている時点でグラフは無茶苦茶なのだが。それはそれとしてまずRead(グラフ107)を見ると、面白いのがやっぱり2 CCDのRyzen 7 7950XやRyzen 9950Xでは一度下がった帯域がまた上がる事。RyzenのIoDは、2つのCCDからのリクエストを均等に割り振るような構成になっているのか、1 CCDの製品ではIoDのフル性能を生かしきれないようだ。あと、1つのInfinity Fabricのチャネルに大量のリクエストを与えると、そこがボトルネックになる様に見える。肝心の絶対的なメモリ帯域そのもので言えば、メモリも共通だしIoDも共通だから、当然大差ない事になる。これは当然と言えば当然であろう。

グラフ108

一方Write(グラフ107)は、そもそもBurstが効かないこともあって帯域が半減し、Memory Busそのものがボトルネックになるためだろうか？ Infinity Fabricのボトルネックは見えない形になっている。

◆Sandra 20/21 31.139(グラフ109～135)

Sandra 20/21 31.139
SiSoftware
https://www.sisoftware.co.uk/

グラフ109

グラフ110

今回はフルバージョン、といってもCache/Memory Latencyを追加しただけだが、こちらをお届けしたいと思う。まずグラフ109/110がDhrystoneであるが、前回そもそもRyzen 5/7は消費電力を抑えている関係で動作周波数も低くなっているのではないか？という推定をご紹介した。では制限が大幅にあがったRyzen 9は？というと、確かに性能があがり、Ryzen 9 9900XですらCore i9-14900Kに肉薄。当然Ryzen 9 9950XはCore i9-14900Kを上回ってはいるのだが、意外にもRyzen 9 7950Xよりはやや低い程度であった。もっとも後で出てくるが、消費電力そのものもRyzen 9 7950Xよりは微減になっており、ほぼ性能と消費電力のバランスが取れた格好になっている。まぁXモデルだから、もっとピーク性能が欲しければ自分でUEFI SetupなりRyzen Masterなりを使ってOC動作すればよく、デフォルトは穏当なところに設定しておく、ということかもしれない。これはこれで理解ができる設定である。あとMT+MCはともかく1TではRyzen 7000系と比較して明確に性能が伸びているのも再確認できた。

グラフ111

グラフ112

Whetstone(グラフ111・112)も傾向は同じである。ちなみに.NETに関しては、スコアを見る限り1T動作でも内部的にはMT+MCに近い動き方をしてるように見える。元々は仮想マシンでの性能比較のために行っていたが、次回やる機会があったらもう.NETは外した方が良さそうだ。

グラフ113

グラフ114

グラフ115

グラフ116

Cryptographic Test(グラフ113～116)であるが、まずAESのEncryption/Decryption(グラフ113・114)はもうメモリ帯域か何かがボトルネックになっているとしか思えない。もっと正確に言えば、メモリコントローラの帯域というかI/Fがボトルネックになっているようだ。結果を見ると、Ryzen 9000シリーズが揃いも揃ってほぼ同じスコアを出している事、それとRyzen 7 7800X3Dが1TではRyzen 9 7950Xを上回っているのに、MT+MCではRyzen 9 7950Xが上回っていることからこれが見て取れる。もうCPU性能に関しては、Ryzen系は完全に飽和している感じだ。

これはHasinghについてもいえる。1Tでの成績を見るとRyzen 9000系はほぼ横並びになっており、Intelと比べて圧倒的に高い性能なのに、MTだとIntelと並ぶ(除SHA-512)というのは、これもメモリ帯域のネックの可能性が高い。

グラフ117

グラフ118

グラフ119

Financial Analysis(グラフ117～119)はDhrystone/Whetstoneと似た傾向になっている。3つともMT+MCで最高速なのはRyzen 9 7950Xであるが、Ryzen 9 9950Xも僅差でこれに続いているという感じになっているが、1TではRyzen 9000系がRyzen 7000系を明確に凌いでいる。要するに消費電力をRyzen 7000シリーズより若干控えめにすることで、同程度の性能に留める代わりに効率を改善する、というスタンスをRyzen 9 9900X/9950Xで取った結果がこのスコアという訳だ。

グラフ120

グラフ121

グラフ122

それでも性能が大幅に向上する場合がある。Scientific Analysis(グラフ120～122)のGEMM MT+MCでは、ダブルスコアとは言わないまでもRyzen 9 9950XがRyzen 9 7950Xの60%近く性能を引き上げているのは、FPUの強化が主な要因だろう。MT+MCだけでなく、1Tの場合でもRyzen 9000系はRyzen 7000系から5割増し程の性能になっている。

FFTはメモリ回りがボトルネックなのか、そこまで性能差が無いが、N-BodyではGEMM並の性能差が再び示されている。要するに演算性能そのものは確かに向上しており、ただしアプリケーション性能は？というとメモリの利用仕方次第というあたりだろうか。

グラフ123

グラフ124

グラフ125

グラフ126

グラフ123～126がImage Processingである。生データは相変わらず見にくいので、相対性能を示したのがグラフ125・126を見て判断すると、こちらはIPCの向上が功を奏しているようで、MT+MCと1Tの両方のケースで明確にRyzen 9000シリーズは大きな性能向上を示している。判りやすいのは1Tの方だと思うが、MT+MCでもRyzen 9 9900X/9950Xの性能はRyzen 7950Xと、多くの場合はCore i9-14900Kを上回るスコアになっており、これはIPCの向上を裏付けるものになっている。1Tの場合もそうで、低いもの(例えばMarvling)ではRyzen 9000シリーズの伸びは11%台だが、高い物(例:Blur)では4倍近い性能向上になっているあたりは、圧倒的とすらいえる。

グラフ127

グラフ128

グラフ129

グラフ130

グラフ127～130がInter-Thread Efficiencyのダイジェストである。まずグラフ127・128がInter-Thread LatencyのBest/Worstであるが、前回には無かった項目にInter-Module Latencyがある。要するにCCDを跨いだ状態でのLatencyの測定で、1 CCDのRyzen 5/7では意味が無い結果であった。これがRyzen 9 9900X/9950Xでは倍近くに増えているのはちょっと意外であった。IoDが共通、という事を考えるとこれはCCD側の問題だと思うのだが、Inter-Coreは若干の高速化(というか低Latency化)が実現しているのに、Inter-Moduleがここまで悪化しているのはちょっと興味深い。つまりZen 5ではなるべく同一CCD内で一つのProcessを走らせるようにするのが得策という訳だ。

Inter-Thread BandwidthのBest/Worst(グラフ129・130)では、特にRyzen 9 9950XのL2付近の帯域の大きさが目を惹く。Ryzen 9 9900XもRyzen 9 7950Xなみの帯域で、これは恐らくAVX512を同時2命令実行できるのに絡み、L2周りの帯域の強化が影響しているのではないかと思う。

グラフ131

グラフ132

Memory Bandwidth(グラフ131・132)では、ことStreamに関してはMT+MCと1Tの帯域が大差ないという謎の結果になっているがこれは恐らくIoDのメモリコントローラ側というかメモリそのものの制約であって、実際RMMTでも8thread位の数値だとRyzen 9000系はReadが76GB/sec、Writeが35GB/sec位だったから、この数字には納得できるものがある。今回だとDDR5-6000×2chだからピークでも96GB/secであり、Streamで半分強が出てるのは十分に高速である。何というか、Zen 5コアを更に高速化したいと思った場合、次にやるべきことはMemory Controllerの高速化とか広帯域化になりそうだ。

グラフ133

グラフ134

Cacheエリアまで広げて帯域を確認したのがCache&Memory Bandwidth(グラフ133・134)で、こちらもMT+MC(グラフ133)より1T(グラフ134)の方が判りやすい。ところで以前の記事でこのグラフ133について「MT+MCでL2 Accessになった途端に帯域が跳ね上がるのは、全コアがL1をフルにぶん回すと消費電力がリミットになり、動作周波数が引き下げられたためであると考えられる。このあたり、Ryzen 9だとTDPがもっと大きいので、また違った傾向になりそうである。」と書いたが、Ryzen 9 9900X/9950Xでも傾向は同じだった(9900Xと9950Xでグラフのカーブの形状が異なるのはちょっと面白いが)。ただこれはあくまでMT+MCの場合で、1Tの場合は当然L1の方が帯域が大きい。要するにL1相手にぶん回すと、簡単に動作周波数がLimitに達してしまい、制限が掛かるというシナリオがやはり一番理屈にあっていることになる。この辺はちょっと不思議である。

グラフ135

グラフ136

グラフ137

グラフ138

グラフ139

グラフ140

さてここからは前回省いたCache&Memory Latency(グラフ135～140)を。今回Memory周りしか性能が変わらなかったので、1Tは省きMT&MCのみとした。また時間(ns)ベースの結果は省き、サイクル数(cycle)ベースの結果のみとしている(Memory Latencyはcycle数で数えるとおかしくなるのでnsベースの結果が必要だが、Memory Latencyは今回対象にしていないため)。

さてまずGlobal Data Memory、要するにData Cache側のPathである。Sequential(グラフ135)を見ると、L1/L2/L3がRyzen 7000シリーズとRyzen 9000シリーズで同じままに見える。In-Page Random(グラフ136)とFull Random(グラフ137)では、なぜかRyzen 9 9700Xのみちょっと早めにLatencyが増加する(16MBあたりからなので、L3の範疇だ)のが気になるが、それ以外は大きな差が見られないというか、Ryzen 9 9700X以外についてはこのL3領域のLatencyが若干ながら減っており、少しアルゴリズムを改善したことが見て取れる。またL2の入りに関してもSequentialでは差が無いが、In-Page Random/Full Randomでは僅かながらLatencyが減っているが、これは誤差の範囲かもしれない。

ではInst/Code Memory、つまりInstruction Cacheの側のPathはどうか？ということでSequential(グラフ138)を見ると、L1～L2では当然ながら差が無い。ところがL3に関しては、Ryzen 9000シリーズは揃ってかなり大きいLatency(60cycle後半)になってるのは、何か違いがありそうだ。この辺は後程RMMAの所であらためて説明したい。

一方In-Page Random(グラフ139)とかFull Random(グラフ140)ではRyzen 9000シリーズの傾向が明らかに異なる。判りやすいのはIn-Page Randomで512KB～、つまりL3に入った領域であるが、ここがL2並みの低いLatencyが維持されている(といっても微妙に増えてはいる)のは、キャッシュ管理のアルゴリズムが何か変わったのだろうか？外部から見ると16-Way Associativityという形でRyzen 7000シリーズと特に違いはないのだが、何かしら手が入っている様だ。

グラフ141

最後にVideo Memory Bandwidth(グラフ41)。前回も書いたが、GPU to CPUでCore i5-14600Kだけ低いのは何かこの時に問題があったのかもしれない。ただCPU to GPUはCore i9-14900Kもかなり低めで、これはプラットフォーム側なのかCPUの問題なのか判断が付きにくい(まぁPCIeのコントローラがCPUに内蔵されている以上、広義にはCPUの問題なのだろうが)。一方のRyzenは7000シリーズと9000シリーズで違いが無いが、IoDが同じなのだからこれは当然だろう。

◆RMMA 3.8(グラフ142～228)

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

久しぶりのRMMAである。前回はこの時だから1年ぶりだ。

ちなみに今回もRMMA環境の構築にはだいぶ苦労。最終的にはWindows 10の環境を用意し、ここで実行した。ちなみターゲットはRyzen 7 9700を使い、動作周波数はBase Frequencyである3.8GHz固定である。以下のグラフでは

Raptor Lake: Core i9-13900K
Zen 4: Ryzen 7 7700X
Zen 5: Ryzen 7 9700X

である。ちなみにCore i9-13900KとRyzen 7 7700Xのデータは前回の時の物をそのまま流用し、ここにRyzen 7 9700Xのデータを加味した形になる。

グラフ142

グラフ143

グラフ144

グラフ145

グラフ146

グラフ147

グラフ148

グラフ149

グラフ150

グラフ151

グラフ152

グラフ153

グラフ154

グラフ155

グラフ156

まずはDecode(グラフ142～156)。久しぶりなのでもう一度繰り返し示すと

テスト名	サイズ	実施する命令
NOP	1Byte	nop
SUB	2Byte	sub eax, eax
XOR	2Byte	xor eax, eax
TEST	2Byte	test eax, eax
XOR/ADD	4Byte	xor eax, eax; add eax, eax
CMP #1	2Byte	cmp eax, eax
CMP #2	4Byte	cmp ax, 0x00
CMP #3	6Byte	cmp eax, 0x00000000
CMP #4	6Byte	cmp eax, 0x0000007f
CMP #5	6Byte	cmp eax, 0x00007fff
CMP #6	6Byte	cmp eax, 0x7fffffff
Prefixed CMP #1	8Byte	rep rep cmp eax, 0x00000000
Prefixed CMP #2	8Byte	rep rep cmp eax, 0x0000007f
Prefixed CMP #3	8Byte	rep rep cmp eax, 0x00007fff
Prefixed CMP #4	8Byte	rep rep cmp eax, 0x7fffffff

の各命令について、どのくらいのThroughputでI-Cacheから取り込んで処理できるかの比較である。

で、NOP(グラフ142)はMicroOp Cacheの効果もあってZen 4でも12 NOP/Cycleをピークで出力出来ている。ただMicroOp Cacheが切れるとZen 4は4 NOP/Cycle程度だったのが、Zen 5では6 NOP/Cycleに強化されている。これは4命令×2のDecoderのうち、NOPの処理が各3命令づつということなのかもしれない。

SUB(グラフ143)/XOR(グラフ144)/TEST(グラフ145)は何れも2Byte命令であるが、SUB/XORがピークで9命令/cycle、その後は6命令/cycle弱なのに対し、なぜかTESTだけMicroOp Cache有効の範囲では8.5命令/Cycle程度に留まっているのが少し不思議ではある。ただその先は概ね6命令/Cycleになっている。Zen 4だと常に4命令/Cycleだし、Raptor Lakeだと5命令/Cycleと6命令/Cycleが混在しており、この辺はZen 5のDecoderの強力さがが判る。ちなみにXOR/ADD(グラフ146)はXORに引っ張られるためか、結果はXORに近いものになっている。また2命令のCMP(グラフ147)もほぼ同じ傾向だ。

さて凄いのはここからだ。4ByteのCMP #2(グラフ148)ではMicroOp Cacheの効く範囲では9命令/Cycle弱まで性能が伸び、L1の範囲でも20Bytes/Cycleに近い。そして6BytesのCMP #3～#6(グラフ159～153)ではMicroOp Cacheの範囲が50Bytes/cycle超えでほぼ9命令/Cycle、そして8BytesのPrefixed CMP #1～#4(グラフ153～156)では70Bytes/cycle超えでこちらも9命令/Cycleである。Zen 4は常に4命令/Cycleどまりだし、Raptor Lakeも5命令/Cycle止まりなのが、Zen 5ではかなり複雑な(Prefixed CMPなんてその代表例だろう)命令でも常にMicroOp Cacheから9命令/Cycleで供給されることが確認された格好だ。このFront Endは、Lunar Lakeに搭載される予定のLion Coveと十分競合できそうだ。

ちなみにこの数字はあくまでMicroOp Cacheからの供給なので、通常のDecodeでは最大でも8命令/Cycle、実際にはL1/L2の帯域がボトルネックになるので6命令/Cycle前後がピークになると思うが。

グラフ157

グラフ158

グラフ159

グラフ160

グラフ161

Decode Efficiency(グラフ157)に関しては、やはりMicroCodeでの処理になると性能が落ちるのは致し方ないが、恐らくこのMicroCodeのPathもダブルで搭載しているためか、Zen 5ではZen 4の1.5倍ほどの性能に向上している。またROB(グラフ158～161)についても、Zen 4ではちょっと独特な構造だったのが再びコンサバティブに戻った格好で、しかもLatencyがRaptor Lakeと比べても十分低い、割と素直な特性になっている(グラフ160のPseudo Randomだとちょっと変動するが、Zen 4の1/4以下のLatencyで収まっている)のは大きな違いと言える。

グラフ162

グラフ163

グラフ164

グラフ165

グラフ166

グラフ167

グラフ168

次がCache周り。まずD-CacheのBandwidth及びLatency(グラフ162～168)であるが、Bandwidthを見るとZen 5ではL1～L2が48Bytes/cycle弱、Writeも48Bytes/cycleと圧倒的にZen 4から強化されている。Copyだと32Bytes/cycleあたりに落ちるのは仕方ないとして、そのCopyもRaptor LakeではL2が12Bytes/cycleあたりまで落ちるのにZen 5では32Bytes/cycleをほぼ維持するあたり、L1/L2の帯域が圧倒的に大きくなっているのが確認できる。これはSandraの結果とも矛盾しない。それでいてLatencyはかなり低く、L2までの範囲では3cycle弱をコンスタントに維持している。ことL2までの範囲で言えば、Zen 5はキャッシュ帯域も広がり、それでいてLatencyも低いという恐ろしく強力なコアであることが見て取れる。

グラフ169

グラフ170

グラフ171

グラフ172

グラフ173

グラフ174

グラフ169～174はL1/L2 D-CacheのAssociativityの確認である。CPU-Zの結果(例えばPhoto05)で、L1 D-Cacheは12-way、L2とL3は16-wayのAssociativityとレポートがあるわけだが、実際L1(グラフ169～171)を見ると確かに12Segmentの所でLatencyが増えており、正しく12-wayであると確認できる。一方L2(グラフ172～174)はL2が1MBという事もあってか、Way数を確認する前にSegmentが溢れてる感じで、本当に16-wayかどうかが確認できないのはご愛敬か。ただそれにつけてもZen 5のLatencyの低さはちょっと驚異的である。Zen 4と比較してもかなり低いし、Raptor Lakeとは比較にならないレベルである。

グラフ175

グラフ176

グラフ177

グラフ178

グラフ179

グラフ180

グラフ181

グラフ182

次がI-Cache Latency(グラフ175～182)。こちらはNear/FarでそれぞれForward/Backward/Pseudo-Random/Randomの組み合わせであるが、L1～L2に関してはどのケースでもZen 5はかなり低く収まっている。ところがNear Forward(グラフ175)とかNear Pseudo-Random(グラフ177)、Far Forward(グラフ179)などでは特にL3領域でZen 5のLatencyが急増している。これは先のSandraのグラフ138にも通じる特性で、BackwardとかRandomとかのLatencyはむしろ低い方に属するので、決して何もしてない訳ではないのだろうが、普通にアクセスするとLatencyが多く、でも変なアクセスをしてもそれほど増えないという妙な結果になっている。可能性としてあるのは、D-Cacheは兎も角I-Cache側からL3を直接アクセスするようなケースは普通は無く、PrefetchによってL1ないしL2にあらかじめ命令が蓄えられ、これを利用するようなケースが一般的であるという事を前提に、必ずしもSequentialには高速ではない管理方式にしているのかもしれない。Prefetchの存在を前提にすれば、そういう実装もありえるからだ。L1/L2が速度優先といった構成なので、L3はまた別の構成になっているのは不思議では無いだろう。

グラフ183

グラフ184

グラフ185

グラフ186

グラフ187

グラフ188

グラフ189

グラフ190

グラフ191

グラフ192

グラフ193

グラフ194

グラフ195

グラフ196

グラフ197

次がTLBであるが、まだZen 5のTLBの詳細が公開されていない(Photo09)。いやエントリ数はこれで判明しており、I-TLBが64/2048、D-TLBが96/4096 Entryであるのは判るのだが、Fully Associativeなのかnn-Way Set Associativeなのかが判らない。Zen 4の世代で言えば、L1 I-TLBとL1 D-TLBがFully Associative、L2 I-TLBが16-way、L2 D-TLBが24-wayだったのだが、その辺の情報はCPU-Zにも出てこないので、確認がてらちょっと試してみた。まずグラフ183～185がD-TLB Sizeの確認で、確かにL1が96 Entry、L2は「1000以上(もっと正確に言えば1096以上」であることが確認できる。で、グラフを見るとまず96 entryを境にまず変化し、次いで200entryを超えたあたりで変化しているあたりは、L2 D-TLBは24-wayを32-wayにしているのかな？という気がしなくもない(L1 D-TLBはこの感じだと多分Fully Associativityだろう)。グラフ186～197を見ると、Zen 5は64 Entrieまではほぼ一定の値をとっており、ところが128 Entriesになると急に暴れはじめるあたりはZen 4と全く同じ振る舞いであるからだ。それにしても、いずれの場合でもZen 4よりLatencyが低く抑えられているのにはちょっと感心する。

Photo09: この記事を書いたときにはまだ提供されていなかったスライド。こうしてみると機能強化が凄まじい。

グラフ198

グラフ199

グラフ200

グラフ201

グラフ202

グラフ203

次いでI-TLB。こちらもNear(グラフ198～200)とFar(グラフ201～203)で別れているが、Zen 5はどちらもL1 I-TLBは64 Entryっぽい数字になっており、その先は1000 Entryまでほぼ一定なところを見ると、間違いなくL2 I-TLBは1000を超えている。グラフ204～227までがI-TLB Associativityであるが、D-TLBの場合と異なりNear/Far共に128 Entryでも暴れ方が非常に穏やかなあたりは、TLBのEntry増加(4倍)に伴いWay数も4倍の64-wayになっている様に思われる。余談だが、コンシューマ向けに2048ものL2 I-TLBが本当に必要なのか？というとちょっと疑問で、明らかにOverkillな気がするだが、この辺は同じダイをEPYCに使う事を考えての方策だろう。