銳龍AI9365測試

這周從某不知名小廠工作的朋友那裡借到了 Strix Point 工程機，有機會在筆記本正式發售前體驗一段時間。於是我運行了一系列的測試，從微架構與性能兩方面提前體驗時隔兩年的 AMD 新微架構。

由於只有幾個小時的時間，這次就只針對 CPU 部分簡單跑了一些現成的跑分而沒有仔細深究微架構的每一個細節。如果有必要，後續 Zen5 量產版本發售之後我會再做一些補充。

處理器參數

Strix Point 系列首發的兩個 SKU 分別是HX 370和365，均僅支持 FP8 封裝。首發時僅支持 LPDDR5x 內存，本次測試的平台為 LPDDR5x-7500 32GB。

在移動端處理器連續4代提供8核移動端處理器、連續3代使用原生8核心的CCX之後，Strix Point 終於大幅度修改了核心配置。Strix Point 是一個原生12核心的處理器，並且由非對稱的兩個 CCX 組成：

• CCX0: 4個核心，搭配 16 MB L3 緩存
• Zen 5 青春版大核心：相比桌面/服務器的完整版 Zen 5，其最高頻率從 5.7 GHz 降低到 5.1 GHz，SIMD 吞吐減半，對應的 L1 向量load帶寬也減半
• CCX1: 6或8個核心，搭配 8 MB L3 緩存
• Zen 5c 小核心：使用與大核完全相同的微架構，在後端物理設計層面繼續降低Fmax target以縮減面積，頻率不超過4 GHz。

最高端的HX 370處理器有完整的4+8核心，大核最高頻率為 5.1 GHz；而本次測試的次高端365則是4+6核心的搭配，大核頻率為 5.0 GHz。由於保留了完整的4個大核並且大核頻率僅降低0.1 GHz，日常使用不會與HX370有非常明顯的差異。

AMD 官網沒有寫明小核參數，經過實測可得365小核頻率為 3.3 GHz，HX 370則只有後續再進行測試才知道。與 Phoenix2 不同的是，Strix Point處理器大小核可同時跑滿各自的最大頻率，而不會出現互相拖累的問題。

微架構特性

與 Zen 4 相對微小的改動不同的是，Zen 5是一個“ground-up”的全新微架構，其地位與 Zen 3 相近。因此它也開啟了新的篇章：CPUID family從19h (25) 改為 1Ah (26)。本文選取了一些比較基礎的微架構測試數據整理發佈。

指令吞吐

使用 InstructionRate 工具分別測量 Zen 3/4/5 的指令吞吐/延遲，

從上面的測試中可以看出，Zen 5 相比 Zen 4 的改動有進有退：

• 大幅度增加各種 scalar ALU 指令的吞吐，但由於移動端Zen 5的向量單元相比桌面與服務器減半，在本次測試中相比Zen 4的SIMD吞吐基本維持不變。即便是在向量單元減半的Zen 5核心上，所有寬度的SIMD store操作依然相比前代翻倍，SIMD load store 吞吐達到 1:1；
• 大幅度增強分支處理能力，每周期可處理的 non-taken branch 從兩個增加到3個，且每周期可處理兩個 taken branch。這個應該與新的前端設計有關；
• 128/256/512bit 的 SSE/A VX/A VX512 SIMD 整數加法計算的延遲全部增加到2周期，這個改動可能是為了讓維持高頻變得更容易；
• 128/256bit SIMD 整數加法運算吞吐相比Zen 4全部減半，但512bit不變。推測這個問題只在 SIMD減半的Zen 5核心上存在，可能與 port 分配有關；
• 移除 Zen 4 引入的 nop fusion 功能。現在不再可以將 nop 指令與另一條指令合併在同一個 macro-op 上；
• 調整了一些邏輯寄存器操作的吞吐，將一部分 mov 以及一部分寄存器 zeroing 吞吐統一為5，相比 Zen 4 有增有減；

從整體上看，Zen 5的後端指令吞吐以增加為主，但也有少部分指令作出了相當大的取捨，部分指令的吞吐偏保守。

取指令、解碼與macro-op cache

Zen 5目前公開的信息里沒有太詳細地提到前端的規模，只有一個提到前端指令吞吐最多翻倍的頁面。

除此之外AMD還提到一個關鍵詞：“Parallel dual pipe front-end”，這個設計讓人聯想到兩年前公布的兩個專利：

• Processor with multiple fetch and decode pipelines
• Processor with multiple op cache pipelines

通過運行不同指令長度、不同指令數量的NOP指令，我們可以較為容易地觀測取指令、解碼與 macro-op cache 的行為。從這個測試中，我們可以看出 Zen 5 的前端相比 Zen 4 有着相當特殊的表現。

首先從2位元組的NOP開始：

在這個測試里，可以看到Zen 5單線程運行2位元組NOP的取指令能力並沒有相對Zen 4表現出任何明顯優勢（除去 macro-op cache 內的吞吐略微提升了一些），且在以下情況下相對劣勢：

• 可觀測到的 macro-op cache 減少。Zen 4在8-12KB（也就是對應4k-6k條指令）的吞吐下降幅度相比Zen 5更為平緩，推測Zen 5將 macro-op cache 減少到與Zen 3相同的4k條；
• 出緩存後從DRAM取指令的帶寬減半，推測單線程最大in-flight L1i$ miss減半。

在這個測試里，Zen 5單個線程依舊是一個4解碼x86核心的表現。但當我們開啟兩個SMT線程一起測試時，可以觀察到吞吐翻倍，指令吞吐在L1-L2乃至L3區間內都達到了8，在DRAM區間也恢復了與Zen 4相同的正常水平。

繼續使用4位元組NOP指令觀察，可以看出Zen 4在這個測試里觸發了NOP融合，因此 macro-op cache的NOP吞吐和等效容量翻倍，而Zen 5則維持了相似的表現——macro-op cache內IPC略大於6，單線程等效為4寬的x86解碼。而4位元組指令不僅會出現DRAM fetch帶寬下降，從L3 fetch也觀察到帶寬減半。開啟SMT後則可在L2內做到8寬解碼，L3 fetch 帶寬也恢復正常。

在8位元組NOP的測試中，由於4096條指令的 macro-op cache 可以完全覆蓋32K L1i，因此無法準確判斷這種情況下的x86解碼性能，只能看出Zen 4/Zen 5各自走 macro-op cache 時的指令吞吐分別為6和8。

從上述測試中可以猜個八九不離十：

• Zen 5採用了與Tremont相似但更寬的多前端設計，採用兩個4寬的x86解碼器，搭配至少8寬的 macro-op cache 實現8寬 rename；
• 考慮以下現象
  • Zen 5單線程運行連續的NOP指令時並不能讓x86解碼帶寬超過4；
  • 在指令吞吐小節中測試得出其單周期可以處理兩個taken branch；
• 合理推測Zen 5沒有採用類似Gracemont的predecode ILD緩存方案，而是必須在分支預測器預測發生taken branch時才能讓兩個解碼同時工作，也就是直接讓其中一個解碼器去從下一個分支目標地址開始解碼。從這個角度來看，AMD本代依然需要依賴 macro-op cache 來實現分支較為稀疏的場景的高吞吐；
• Zen 5不僅要支持同一周期從兩個位置開始解碼 x86 指令，也要支持同一周期從 macro-op cache 中的兩個位置分別 fetch 指令，以實現 macro-op cache 覆蓋範圍內的每個周期處理兩個 taken branch；
• 當核心運行兩個SMT線程時，可以各自獨佔一個解碼器使整個核心的x86解碼吞吐上限在大部分情況下達到8。

由於時間和測試條件關係，本次暫時沒有收集性能計數器數據結合實際跑分來觀察新的前端表現，因此僅僅只能進行一些簡單的理論分析。

個人推測在不久的將來，macro-op cache可能會被從 Zen 核心上完全移除，從而轉向更為靈活的predecode ILD緩存方案來解決x86可變長度寬解碼問題。同時，AMD可以增加多組解碼器的數量以輕鬆為高性能核心實現更寬的x86解碼（同時支持單周期處理更多的 taken branch），或減少解碼器數量為低功耗核心實現更節能、面積更小的x86解碼。

訪存延遲與帶寬

Zen 5並沒有對緩存容量和核心拓撲進行非常大的改動，因此跑一些比較常規的測試。

從上圖可以看出，

• Zen 5將L1緩存增加到48 KB並且延遲維持4周期不變。
  L1延遲性能優於Ice Lake之後實現48KB L1的微架構，與即將發佈的 Arrow Lake (Lion Cove) 相同。
• L2延遲屬性整體維持不變（1MB 14周期）
• L3延遲從50周期降低到46周期左右。
  考慮到Zen 5的頻率並沒有非常大的下降，可以認為它的L3延遲獲得了小幅度進步。

接下來進行SIMD讀取帶寬的測試，

可以看出，

• SIMD規格減半的Zen 5的L1讀取帶寬與Zen 4基本相同，均為每周期64位元組；
• 與L1不同的是，L2帶寬翻倍的屬性被保留；
• 單線程讀取L3的帶寬更接近理論的每周期32位元組，而Zen 4隻有每周期24位元組左右。

跨核心同步

Strix Point 處理器再次引入雙CCX設計引發了一些人對跨CCX同步性能的擔憂，因此本文也進行了簡單的跨核心同步的性能測試。

可以看出，Strix Point的兩組核心在不同的CCX內，表現與一般的 Ryzen 沒有什麼明顯區別。跨 CCX 同步的延遲偏高（大約是桌面 Ryzen 的兩倍左右），可能與 FCLK 頻率動態調節等因素有關。

性能實測

由於時間關係，本次選取了SPEC CPU 2017 rate-1、Geekbench 5/6的單核/多核，分別對高頻的Zen 5以及低頻的Zen 5c進行測試。

• 其中Geekbench測試時間較短，因此所有設備運行於默認最高頻率（frequency governor配置到“performance”）；
• SPEC CPU 2017運行時間較長，其中500和548等子項的局部發熱非常嚴重，單核運行測試也會撞溫度牆。在對Ryzen AI 9 365進行測試時，部分情況下頻率會降低到4.9 GHz左右。為獲得準確數據，在SPEC測試中將所有處理器使用CPPC限制到4.8 GHz同頻對比。
• “Relative Performance”以7735U為基準，計算所有其它處理器的提升幅度
• “IPC uplift”則以前代為基準計算IPC提升幅度。Zen 4的IPC提升幅度相對Zen 3計算，Zen 5/5c相對Zen 4計算。

SPEC CPU 2017

觀察子項成績可以發現，500.perlbench_r的提升較大，達到了24%。而525.x264_r幾乎沒有性能提升，531.deepsjeng_r甚至發生性能下降(-5%)。以這三個測試為例進行一些簡短的分析（猜測為主）：

• perlbench是AMD的傳統劣勢，其性能瓶頸被L1容量、load/store能力的提升很好地緩解。除此之外perlbench的ILP較好，分支指令數量適中，可能可以較好地發揮新的前端吞吐提升；
• x264主要是執行單元瓶頸，編譯器自動向量化生成了大量SIMD整數運算代碼。通過前面的分析可以發現，Strix Point上的Zen 5不僅在這方面毫無進步，甚至還有相當大的退步。那麼微架構方面的提升極有可能被這些SIMD方面的削減抵消，想要在這個測試里獲得完整的Zen 5性能可能只能等待桌面版；
• 在之前針對Zen 4運行SPEC的性能計數器分析中可以看出，531子項哪怕是在擁有 6.75K macro-op cache 的Zen 4核心上運行也會造成相當高的 macro-op cache MPKI。而Zen 5這方面有較為明顯的削減會進一步拉低命中率，推測IPC下降與此有一定的關聯。

總之，在有條件收集性能計數器數據之後，我會對跑分進行更詳細的性能分析。

Geekbench

從整體看，Zen 5在 Geekbench 5/6 中的IPC提升比較符合官方宣傳（在沒有 FP/ML 子項刷分的情況下做到了大約15%-17%的提升），好於 SPEC CPU 2017 int rate 的提升。

需要注意的是，Geekbench 6 的 Object Detection 子項會使用 A VX512-VNNI 或者 A VX-VNNI 進行加速，因此 Zen 4相比 Zen 3 在此項測試中性能超過翻倍，拉高了平均數。而移動端 Zen 5 相比 Zen 4 並沒有提高 A VX512 吞吐，在此項測試中的提升並不佔優。由於 Geekbench 6 的這些改動，我認為 Geekbench 5 的整數子項放在今天依然比 Geekbench 6 更加具備參考價值。

總結

Zen 5 是世界上首個 8-wide rename 的 x86 微架構。本次 AMD 一反常態地將 Zen 5 移動端 APU 首先展示出來，但不幸的是無論是大核還是小核都並非性能最好的完全體。移動端一如既往減半的緩存、以往沒有出現過的減半 SIMD 單元、較上代更低的頻率，無不意味着 Zen 5 移動平台和桌面版本的綜合性能差距將會來到史無前例的級別。

好在通過測試 Strix Point 已經可以足夠了解這個微架構的設計思想和最重要的新特性，以解答那個老生常談的問題——x86 作為一個複雜的變長指令，在這個RISC當道的時代，未來應該何去何從？在我看來，當 Intel 目前最有活力的 atom 團隊與後來者 AMD 給出了相同的結論時，我相信答案已經離我們不遠了。期待後續有機會進行更多的詳細完整測試。

聲明：本文僅為博主 Da vid Huang個人測試，測試使用的一切設備、工具等資產與本人所在公司/職位無關，也沒有接受任何贊助。由於使用非正式版系統固件/軟件，測試結論可能與零售設備有少許差異，僅供參考.