关于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期内容，欢迎关注。

加星标⭐️第一时间看推送，小号防走丢

求推荐