關于AMD ZEN 6，一些看法

公眾號記得加星標??，第一時間看推送不會錯過。

12 月 12 日，AMD 更新了其技術文檔，并發布了“ AMD Family 1Ah Model 50h-57h 處理器的性能監視器計數器”， InstLatX64首先注意到了這一點。

AMD尚未正式解釋AMD Family 1Ah Model 50h-57h處理器的具體信息，但這份文件的文件名是“69163-VenicePMC-pub.pdf”，這清楚地表明它是一款Venice處理器——也就是基于Zen 6架構的EPYC處理器。我（指代本文作者）認為可以肯定地說，這是首份關于Zen 6內部配置的文件。

從性能監控計數器中了解到的事實

什么是性能監視器計數器？它記錄 CPU 的內部性能狀態，并在使用名為 Profiler 的信息采集工具分析性能時使用（包含此 Profiler 的分析工具名為“ AMD μProf Performance Analyzer ”）。

順便一提，AMD μProf 性能分析器是“ AMD μProf 開發工具” 的組件之一，并且可以免費使用。撰寫本文時，最新版本為 5.2 版，于 12 月 11 日發布，而上述文檔于次日發布，這意味著 Zen 6 架構的支持預計將在下一個 μProf 版本（5.3 版？）中實現。

性能監視器計數器并非 Zen 6 的新功能，它已經推出一段時間了。EPYC 9005 系列（或 Zen 5 EPYC）的相關說明請參見本文檔。

到目前為止一切正常，但有一家網站開始聲稱，關于 Zen 6 兼容性能監視器計數器的文檔，Zen 6 并非 Zen 5 的擴展，而是一種面向吞吐量的架構。這篇文章來自 Tom's Hardware，隨后許多信息網站開始對此大肆宣傳，聲稱 Zen 6 的內容與 Zen 5 有顯著差異。

你在 Zen 5 中一開始就用的是 8 格寬的布局嗎？

然而，我讀完之后，覺得情況并非如此。因此，我想更認真地審視一下這份文件。

首先，確定性能監視器計數器的位置。

每個線程有 6 個性能事件計數器，每個 L3 復合體有 6 個性能事件計數器，每個數據結構有 16 個性能事件計數器。

可以使用 RDPMC（讀取性能監控計數器）命令讀取每個性能事件計數器。

RDPMC[5:0] 訪問核心事件，RDPMC[9:6,1B:10] 訪問數據結構事件，RDPMC[F:A] 訪問緩存事件。

這是 Zen 5 和 Zen 6 的共同點。

接下來，我們比較一下通用性能統計數據（圖 1）。左側為 Zen 5，右側為 Zen 6。黃色表示變化，綠色表示新增內容。核心本身并無特別變化，主要區別在于，當 L1 數據緩存填滿時，現在可以獲取更詳細的填充來源信息；除此之外，沒有其他區別。

第三部分是流水線利用率分析統計數據的比較（圖 2）。就指令流水線而言，左側是 Zen 5，右側是 Zen 6。

這里對“總派遣槽位”的解釋實際上有所不同（黃色部分），但可以確定這實際上是 Zen 5 方面的一個拼寫錯誤。

這是因為公式中明明寫著“一個周期內最多可以分派 6 條指令”，但實際公式卻是“8 * 事件”，這顯然很奇怪。而且，這與 AMD 的解釋也不一樣。

圖 3 展示了 Zen 5 的內部結構，這在去年的 Hot Chips 上已經解釋過了。在前端的末尾，在 MicroOp 隊列下方，可以清楚地看到“Dispatch 8-wide”的字樣。

Tom's Hardware 的文章指出，Zen 6 將采用“面向吞吐量的寬設計，配備八槽調度引擎和同步多線程”，這讓人很難不聯想到 Zen 6 的 8 槽解碼結構與 Zen 5 相同。因此，流水線似乎不會發生顯著變化。

但這并不意味著沒有改進的空間

兩者之間存在一些差異。例如，計數器 PMCx003（FP 退役的 SSE 和 AVX FLOPs）（圖 4）的有效值在 Zen 5（左側）中被“保留”6-7 小時，但在 Zen 6（右側）中則被分配給了 FP16 的“標量半部分/打包半部分”。這表明 Zen 6 支持 Zen 5 不支持的 AVX512-FP16（打包 FP16）以及 FPU 中的 FP16（標量 FP16）運算。

一個有趣的新增功能是 PMCx00F（FP 打包的 512 個微操作，由 FP 或 INT 類型退役）和 PMCx013（FP NSQ 讀取停頓）（圖 5）。

奇怪的是，PMCx00F 和 PMCx013 都未出現在 Zen 5 架構中，但這可能只是因為當時的技術尚未成熟。PMCx00F 用于監控 512 位操作（即 AVX512 操作模式），而 NSQ 用于監控非調度隊列的狀態。這兩個模塊在 Zen 6 之前就已經存在（512 位 AVX512 操作在 Zen 5 架構中就已經實現）。相反，PMCx18E（IC 標簽命中/未命中事件）（圖 6）不知何故在 Zen 6 中被移除。

最明顯的區別在于 PMCx0AF（動態令牌調度停頓周期 2）（圖 7）。左側的 Zen 5 代架構統一處理所有調度組，而右側的 Zen 6 代架構則會檢查整數調度器 1-6 和 Retire 的令牌是否存在。這使得我們可以更詳細地監控哪些調度器處于空閑狀態。

事實上，這里有六個調度器，由于上面的圖 2 中有一個拼寫錯誤，似乎有人做出了奇怪的解釋，認為 Zen 6 將 8-Wide 調度引擎分成了六個域，但請再看一下這里的圖 3。

在 Zen 5 架構中，調度器已經是 8 路寬。輸出的整數部分在進入調度器之前會被重命名，而調度器在 Zen 5 架構中已經是 6 路寬?；蛘吒_切地說，我唯一能理解的信息是，已經實現了 6 個 ALU，并且計數器配置已更改，用于衡量這些 ALU 的調度效率。

順便一提，Zen 6 中已經實現了這一點，這也意味著 Zen 5 和 Zen 6 之間這方面的結構并沒有改變。

Zen 6 是 Zen 5 的改進版。

除此之外，我沒發現其他任何區別（就我所知）。簡而言之，雖然也有像 PMCx18E 這樣的例外，但目前 Zen 5 和 Zen 6 之間的主要區別在于 Zen 6 現在可以提供更詳細的性能計數器，并且 FPU/AVX512 增加了對 FP16 的支持。我從這份文檔中沒有找到任何關于設計策略根本性變化的信息。

我認為，結構本身將與圖 3 幾乎相同。但是，我認為在改變結構之前有很多事情可以做，例如改進將 x86 指令轉換為 MicroOps 的方法，改進調度器中的調度技術，以及改進分支預測（目前還不清楚它們是否仍然基于 TAGE）。

即使現在，它仍然擁有相當強大的流水線，包含 8 個指令解碼和 10 個指令分發，但其性能是否得到充分利用仍值得商榷。下一代架構，即 Zen 7 及更高版本，可能會采用更廣泛的解碼和分發方式，但 Zen 6 架構在 Zen 5 的基礎上朝著提升效率的方向發展，這似乎是合理的。

首先，吞吐量計算正是推土機架構的核心設計理念，而推土機架構過去曾遭遇慘敗，所以我認為AMD現在不會重蹈覆轍。此外，如今對吞吐量的重視主要集中在AI工作負載上，因此與其調整CPU流水線，不如直接安裝能夠高速執行矩陣運算的加速器，例如AMX或（Arm的）SME2，這樣更便捷高效。

https://pc.watch.impress.co.jp/docs/column/tidbit/2073493.html

（來源：編譯自pcwatch）

*免責聲明：本文由作者原創。文章內容系作者個人觀點，半導體行業觀察轉載僅為了傳達一種不同的觀點，不代表半導體行業觀察對該觀點贊同或支持，如果有任何異議，歡迎聯系半導體行業觀察。

今天是《半導體行業觀察》為您分享的第4266期內容，歡迎關注。

加星標??第一時間看推送，小號防走丟

求推薦