AMD Zen 5大猜想

由半导体行业观察（ID：icbank）编译自chipsandcheese，谢谢。

最近，一位名为 Moore's Law is Dead 的 YouTuber 最近泄露了几张有关 Zen 5 的 AMD 幻灯片。我通常觉得这些泄露无趣，因为它们无法验证，而且通常与现实不相符。

AMD 正在两条战线上与两个更大的竞争对手展开竞争，并且十多年来一直没有对 Nvidia 取得决定性的领先优势。AMD 有望在下一代、每一代（或两代）中创造奇迹，但令所有人惊讶的是，这并没有发生。

然而，这次泄漏值得一提，因为它包含一张包含架构信息的幻灯片。我不知道泄露的幻灯片是否真实，但是构建一个包含大量细节的连贯图片比捏造一些性能数据要困难得多。考虑到这一点，让我们逐点深入研究幻灯片。我不会尝试验证或反驳谣言，而是尝试为每个点提供背景信息，以便您可以得出自己的结论。

分支预测

分支预测器控制 CPU 的管道（pipeline），使其对能效和性能至关重要。如果分支预测器花费太长时间来猜测分支要去哪里，它可能会占用 CPU 管道的其余部分。如果猜错了，核心就会浪费时间和精力做无用的工作。泄露的幻灯片在分支预测器下提出了三点，即零气泡条件分支、高精度和更大的 BTB。

零气泡（Zero Bubble）条件分支（conditional branches）

“零气泡”分支是指在不延迟流水线中后续指令的情况下处理分支。如果后来的指令被延迟，就会类似于输送液体的管道中出现气泡。太多的气泡会减少管道输送的液体量，如果您的生产受到管道输送液体量的限制，这可能会成为一个问题。

A64FX 分支预测和微架构手册中的获取管道。由 Clam 添加的红色和绿色注释

自 Zen 1 以来，AMD 已经可以实现零气泡分支，尽管零气泡预测器可以跟踪很少的分支。Zen 3将零气泡BTB（分支目标缓存）扩展至覆盖1024个分支，使零气泡分支成为典型案例。Zen 4 延续了这一点，并将零气泡 BTB 容量扩展到 1536 个分支目标。因此，零气泡支化并不是什么新鲜事。零气泡条件分支也不是什么新鲜事。在每一代的Zen 中，无论分支是有条件的还是无条件的，都可能发生零气泡分支。

无条件分支和有条件分支之间没有太大区别

AMD 也不孤单。英特尔的 Haswell 可以跟踪 128 个分支并毫无气泡地处理它们。因此，英特尔早于 AMD 就实现了零气泡分支来处理常见情况。自Zen 3以来，AMD已经能够以零气泡速度处理更多分支，但英特尔在这方面仍然非常令人尊敬。

因此，“零气泡条件分支”（zero bubble conditional branches）并不是一个令人兴奋的点。Intel、Arm 和 AMD 的现有 CPU 本身已经可以处理零气泡的条件分支。也许Zen 5增加了零气泡预测能力，但幻灯片上并没有这么说。

高精度、更大的BTB

AMD 在每一代产品中都提高了分支预测器的准确性。Zen 2、3 和 4 通常可以比其英特尔竞争对手实现更好的分支预测准确性。Zen 5 肯定会保持这一领先地位。但说桌面 CPU 具有“高精度”分支预测就像说客机具有加压舱一样。你期望它会发生，如果没有，那就是新闻了。即使是更旧、更简单的分支预测器（例如 AMD Phenom CPU 上的分支预测器）也可以正确预测绝大多数分支。

BTB （branch target buffer）代表“分支目标缓冲区”，它是分支目标的缓存。如果分支的目标被缓存，预测器可以告诉 CPU 从哪里获取下一条指令，而无需等待分支指令到达核心。这可以减少前端延迟，尤其是在必须从 L2 或更高层获取分支指令的情况下。AMD 在每一代产品中都对 BTB 大小进行了调整，但仍落后于英特尔的最佳水平。

Golden Cove的L3 BTB容量比AMD上一级L2 BTB多50%，前端延迟是Zen 4在游戏中的一个问题。这对英特尔来说也可能是一个问题，两家公司都将在晶体管预算允许的情况下尝试扩大分支目标缓存容量。

基本块获取（Basic Block Fetch）

基本块是具有一个入口点和一个出口点的代码块。分支将终止基本块，即使它是有条件的并且并不总是被采用。现有的 AMD（和 Intel）CPU 已经可以跨基本块获取，因为它们可以跨未采用的分支获取。AMD 幻灯片上的观点可能意味着几件事。

假设的基本块示例。假设没有任何东西可以跳到 block1 的中间，并且这些块在内存中连续布局

最简单、最可能的解释是，Zen 5 可以像过去 20 年来制造的任何高性能 CPU 一样跨基本块进行获取。通常，对营销声明最无聊的解释就是正确的解释。

CPU 通常可以跨未采用的分支边界进行读取，从而在单个周期内读取两个基本块

也许 Zen 5 可以跨过已获取的分支。Intel 和 Arm 的最新 CPU 已经做到了这一点。Rocket Lake 可以在其循环缓冲区内展开小循环，从获取的角度将已采用的分支转变为未采用的分支。Arm 的 Neoverse N2 和 Cortex X2 还可以通过使用 64 入口 Nano-BTB 维持每个周期两个采取的分支。此功能可以帮助提高高 IPC 但分支代码的前端带宽。如果某个架构功能已经存在了足够长的时间，可以被多个制造商实现，那么它就有更好的机会出现在新的内核中。在不完全疯狂的情况下，您可以根据泄露的幻灯片希望 Zen 5 能够在每个周期维持多个分支。

获取已采取的分支更加困难并且需要

最后，AMD 之前在 Zen 3 中成为常见情况时宣传过零气泡分支处理。他们没有提到 Zen 1 或 Zen 2 的零气泡分支处理，尽管两者执行零气泡分支的能力都很有限。也许 Zen 5 可以在常见情况下跨基本块获取，而不是像 Intel 和 Arm 那样使用循环缓冲区或微型 BTB。这可能需要双端口指令缓存或微操作缓存以及能够在每个周期提供两个分支目标的大型 BTB。Zen 5 还需要电路将两个获取块合并到下游阶段可以使用的缓冲区中。我认为实施这样的策略没有什么意义。它只对受前端吞吐量限制的高 IPC 代码有帮助。由于指令缓存未命中而导致的前端延迟是一个更大的问题。

加载/存储

每一代 CPU 都会看到内存子系统发生变化，以减少和隐藏延迟。

增加 L1D 容量

泄露的幻灯片显示，Zen 5 具有 48 KB 12 路组关联 L1 数据缓存，与 Zen 4 的 32 KB、8 路 L1D 相比，容量和关联性更高。令人印象深刻的是，该幻灯片声称延迟保持在 4 个周期。英特尔对 Sunny Cove 的 L1 数据缓存做了同样的事情，但延迟从 4 个周期增加到 5 个周期。

Zen 5 更大的 L1D 将获得更高的命中率（Zen 5’s larger L1D will enjoy increased hitrate）。更高的容量有助于减少代码序列的工作集超出缓存容量的情况。较高的关联性有助于防止缓存容量充足但太多“热”地址冲突到同一组的冲突未命中（conflict misses）。

我很惊讶 AMD 能够实现这一目标，因为 12 路关联性意味着缓存访问涉及 12 个标签比较。Zen 使用微标记方案，通过比较部分标记来预测哪个缓存方式（如果有）会命中，但比较 12 个微标记仍然不是开玩笑。幻灯片还显示 Zen 5 每个周期可以执行 4 次负载。这需要 48 次标签比较。

更大的DTLB

所有现代 CPU 都使用虚拟内存。程序存储器地址并不直接寻址 DRAM 芯片上的位置。相反，操作系统为每个进程设置虚拟地址到物理地址（页表）的映射。因此，行为不当的进程不会超越其他所有进程并迫使您重新启动计算机，因为它对系统内存的访问受到限制。

然而，虚拟内存地址必须转换为物理地址。如果 CPU 检查每次内存访问的页表，则延迟会急剧上升，因为每次程序内存访问都会变成多个相关的内存访问。因此，CPU 使用 TLB（翻译后备缓冲区）来缓存常用的翻译。

x86-64 4 级分页，如 Intel 开发人员手册中所述。Clam 用红色添加的简单英文注释。

Zen 4 已经实现了一级数据 TLB 大小从 64 个条目增加到 72 个条目。由于其尺寸较小，第一级 TLB 是完全关联的。这消除了冲突遗漏，但意味着任何 TLB 条目都可以包含所需的翻译。每个周期四次数据高速缓存访问可能需要每个周期超过 72 * 4 = 288 个 TLB 标签比较。我不确定 Zen 5 如何在不影响延迟的情况下增加 DTLB 大小，除非 AMD 放弃完全关联方案。

我可以看到 Zen 5 使用具有 128 个条目的 16 路集关联 DTLB 或类似的东西。检查它比使用 64 个条目的完全关联 TLB 更容易，并且更大的容量足以最大限度地减少冲突遗漏。或者，Zen 5 可以保持第一级 DTLB 不变，并增加 L2 DTLB 容量。Zen 4 已将 L2 DTLB 大小提高到 3072 个条目，而 Zen 3 中为 2048 个条目。增加 L2 DTLB 大小将有助于热内存占用达到数兆字节范围的程序。

更大的 PWC（页面遍历缓存：Page Walk Cache）

地址转换不一定是一种全有或全无的情况，即您要么命中 TLB，要么进行整页遍历。当 TLB 无法包含程序的工作集时，CPU 可以缓存上层分页结构，以减少页面遍历延迟。

页面遍历缓存的实现可能有所不同。您可以缓存较高级别并覆盖更多地址空间，或者缓存较低级别并进一步缩短页面行走时间。

这使得页面遍历器从较低的级别开始，从而以更少的内存访问完成页面遍历。每个页遍历缓存条目比 TLB 条目覆盖更大的内存区域，因此非常适合处理内存占用比 L2 DTLB 可以合理覆盖的内存占用更大的程序。例如，缓存的页目录指针表条目将覆盖 1 GB 的地址空间。

我在 Reddit 上看到很多评论，人们说他们不明白我的文章，所以我可以用现实生活中的类比用简单的英语来解释这一点。想象一下，您需要带着您的狗走过四个街区。你希望它完成得更快。一个明显的答案是建造一个投石机，可以将你和你的狗扔下两个街区。然后，您可以开始步行，靠近目的地。由于目的地不同，您需要建造 64 个面向不同方向的投石机。现在，您拥有了现实生活中的步行缓存。

如果您建造了更强大的投石机，您就可以开始距离目的地更近的步行。但功能较弱的设备可能会将您带到距离许多目的地仅几步之遥的地方。您可以建造许多更强大的投石机，但这会消耗更多的面积（和树木）。CPU 架构师必须做出同样的权衡。

自 Zen 1 以来，AMD 使用了 64 条目页目录缓存 (PDC)：page directory cache ，用于保存页目录指针表和页映射 4 级条目。L2 TLB 条目可以缓存页目录条目。也许 Zen 5 最终增加了 PDC 尺寸。或者，与直接转换相比，AMD 为加载/存储单元提供了更强的偏好，以在 L2 TLB 中缓存页目录条目。

高吞吐量

Zen 世代在核心吞吐量方面取得了适度的改进，因为核心吞吐量通常不是限制因素。Zen 1 和 2 每个周期可以维持 5 条指令，而 Zen 3 和 4 每个周期可以维持 6 条指令。由于指令和数据侧内存访问性能的大幅改进，AMD 每一代都取得了两位数的 IPC 收益。

AMD Zen 3 Hot Chips 演示的幻灯片显示 IPC 收益主要来自数据和指令方面的内存访问改进

但少数高 IPC 应用程序可能会受益。

8-Wide 调度/重命名

每一代Zen都至少有 8-wide frontend和 8-wide retire。然而，调度/重命名阶段只有 6 个微操作宽。如果 Zen 5 将重命名/调度设为 8 宽，则每个周期将能够维持 8 个微操作。

摘自三星的论文《三星 Exynos CPU 微架构的演进》

这一变化将有利于少数受核心宽度限制的高 IPC 应用。游戏等较低 IPC 应用程序不会从这一变化中获益，因为它们主要受到缓存和内存延迟的限制。

Op Fusion

CPU 可以通过将相邻指令融合到单个微操作中来实现更高的吞吐量并更好地利用内部缓冲区。分支融合是最常见的例子。x86 上的条件分支涉及使用设置标志的指令，然后根据标志跳转（或不跳转）的分支。Intel 和 AMD 已经融合这种 ALU + 条件分支对很多代了。Arm 最新的内核对等效的 ARM64 序列执行相同的操作。

Zen 3 允许将 ADD、AND 和 XOR 等简单 ALU 指令与后续分支以及 CMP 和 TEST 融合，从而改进了 AMD 的融合功能。因此，Zen 3 上的一个微操作可以执行数学运算，检查结果的条件并对其进行分支，然后将结果写回寄存器。Zen 4添加了NOP融合和XOR+DIV/CDQ+IDIV融合。后者处理 x86 除法指令的常见使用模式。

也许Zen 5扩展了融合案例，但幻灯片并没有这么说。据我们所知，这张幻灯片可能会重申 Zen 4 上已经存在的功能。前几代 Zen 已经涵盖了最常见的融合案例（分支）。Zen 4 的改进追求的是收益递减。NOP 用于对齐代码，并且应占执行指令的一小部分。众所周知，除法非常昂贵，大多数编译器都避免使用除法。如果Zen 5增加融合案例，它可能会进一步追求收益递减。

更大、更统一的调度程序

调度程序位于乱序 CPU 的核心，让它们实现高指令级并行性。每个周期，调度程序都必须监视哪些寄存器被写入，并查看挂起的指令是否需要这些输入。它还必须选择已准备好所有输入的指令并将其发送到执行单元。如果无法在一个周期内完成所有这些，则会导致约 10% 的 IPC 损失，因此大型、快速的调度程序非常难以设计。小型调度程序很容易快速实现，但可以快速填充并防止核心隐藏延迟。幸运的是，工程师有很多可用的调度程序布局选项。

在分布式调度程序中，每个执行端口都有自己的私有调度程序。这简化了调度器设计，因为每个调度器只需在每个周期选择一条指令来执行，并且只需要足够的条目来保存预计等待该端口的待处理指令的一部分。然而，调整很困难，因为即使调度程序条目在其他地方可用，一个调度程序也可以填充并阻止重命名器（renamer）。

来自Henry Wong 的博士论文，展示了分布式调度器的设计空间

统一调度程序通过让一个调度程序服务多个端口来避免该问题。每个调度程序条目都可以保存一条发往任何端口的指令，因此可以更好地容忍一个执行端口的突然需求激增。然而，统一调度程序必须在每个周期选择足够的指令来为其所连接的所有执行端口提供数据。天下没有免费的午餐。

AMD 的 Zen 核心混合使用了分布式和统一调度程序。与分布式调度程序一样，有多个调度程序，但有些调度程序如统一设计中那样服务于多个端口

AMD、Intel 和 Arm 最新的 CPU 混合使用了这两种方法。Zen 5 的调度程序更大、更统一，这意味着它有更多的总条目，并且可以更有效地使用其中一些条目。

是什么填满并导致几场比赛中的重命名/调度停顿

从几个游戏工作负载来看，整数调度程序 0 的填充频率比其他调度程序要高一些。Cinebench 2024 在整数方面看到了类似的行为。

调度程序 0 为 AGU 管道和 ALU/分支管道提供数据。AMD 可以选择扩大该调度程序或将其与另一个调度程序统一。他们也可以结合这两种方法。然而，改进的范围可能有限。与整数调度程序相关的调度停顿占个位数百分比，表明 Zen 4 的分布式调度程序已经得到很好的调整。

6 个 ALU、4 个加载、2 个存储

幻灯片显示 Zen 5 有 6 个 ALU，每个周期能够执行 4 次加载/2 次存储。ALU（算术逻辑单元）是能够处理最常见整数指令（例如加法和按位运算）的执行单元。所有前代 Zen 都有 4 个 ALU，因此 Zen 5 将每周期标量整数吞吐量提高 50%。

此更改的影响微乎其微。我将这一部分放在调度程序之后，因为如果执行单元无法跟上传入操作，调度程序将被填满。调度程序也可以由于缺少执行端口以外的原因进行填充。例如，一系列受延迟限制的指令也将填充调度程序。因此，调度程序限制的调度停顿是核心执行单元限制频率的上限。从上面来看，这种情况并不经常发生。

增加加载/存储吞吐量可能有助于特定场景，例如内存副本，其中内核每个周期可以维持 2 次加载和 2 次存储，但这对一般情况有多大影响，我不知道。

ALU 和 AGU 本身很小，但feeding 它们却比较困难。每个新的执行端口都需要来自寄存器文件的输入，并且增加寄存器文件端口计数将增加面积。更多的执行端口意味着调度程序必须在每个周期选择更多的指令，也需要更多的功率和面积。

获得 6 个 ALU 和 4 个加载/2 个存储的方法并不是非常昂贵

如果我是 AMD 并且必须实现 6 个 ALU 和 4 个 AGU，我会使用绝对最少的额外端口来实现。AGU 端口可以作为 ALU 端口执行双重任务，因为 AGU 无论如何都必须对寄存器输入进行简单的数学运算。分支端口还可以升级为 ALU，再次重用现有的寄存器文件端口。

增加执行单元吞吐量将导致最小的收益，但如果以低成本实现，最小的收益也是值得的。我怀疑 AMD 正在走这条路。

更大的结构尺寸

无序 CPU 具有跟踪指令状态的结构，直到最终结果为止。结构尺寸往往随着每一代 CPU 的增加而增加。泄露的幻灯片表明 Zen 5 也会这样做，但没有透露具体细节。

在 Cinebench 2024 和测试的游戏中，Zen 4 的重新排序缓冲区是造成大多数停顿的原因。重新排序缓冲区跟踪后端的所有指令，直到它们按顺序提交。它是 CPU 可以提前停止指令多远的上限。填充重新排序缓冲区并不是一件坏事，因为这意味着特定指令类别的其他队列足够大，本身不会成为限制。

AMD 在每一代 CPU 中都增加了重排序缓冲区容量。Zen 5 几乎肯定也会出现增长，但我们不知道增长到什么程度。随着重新排序缓冲区容量的增加，AMD 还必须增强其他结构，以防止它们在 ROB 之前填满。存储队列已经可以使用更多条目，并且是优化的主要候选者。然而，增加存储缓冲区大小将很困难，因为它必须保存待处理的存储数据。对于 Zen 4，每个存储最多 32 字节。

64 Byte Fills/Victim

幻灯片上的这一行讨论了缓存。“Fills”是指缓存填充，“victim”是指从缓存中踢出的行，以便为填充数据腾出空间。我很困惑，因为最近历史上的每个 CPU 都使用 64 字节缓存行，这意味着缓存管理数据64 字节粒度。因此，数据一次被逐出 64 个字节，并一次被引入 64 个字节。这不是值得一提的一点。

数据预取改进

更好的缓存和更高的重新排序能力分别通过减少延迟和允许执行超过延迟限制的指令来帮助解决内存延迟问题。预取通过尝试在指令请求之前获取程序所需的数据来计算内存延迟。同样，该幻灯片没有详细说明，因此我将提供有关 Zen 4 功能的背景信息。

在 Zen 4 中，AMD 在 L1 和 L2 级别都有预取器。Zen 5 可能会保留相同的预取方法，但允许它们进一步预取，利用更成熟的 DDR5 实现提供的任何带宽增加。AMD 还可能调整预取器，以确保在带宽需求较高时（例如在多核工作负载期间），需求请求获得优先权。

更好的AVX-512

Zen 4 采用 AMD 的第一个 AVX-512 实现。与 AMD 的第一个 SSE 和 AVX 实现不同，Zen 4 没有将在 512 位向量上运行的指令分解为两个微操作。它具有全宽 512 位向量寄存器，并将 AVX-512 数学指令保留为一个微操作，直到一次执行 256 位。

摘自 AMD 在 ISSCC 上的演讲

保持与 Zen 2 和 Zen 3 相同的 FP 执行吞吐量有助于 AMD 获得最重要的 AVX-512 优势（更有效地利用后端资源），而无需大幅增加芯片面积和功耗。

幻灯片上写着“FP Pipes/Units at 512b”。最乐观的解释是 Zen 5 具有 2×512 位 FP 向量执行。即使在台积电较新的 4 nm 工艺上，我认为当大多数消费应用程序不使用 512 位向量时，也会消耗太多的面积和功耗。也许 AMD 会像英特尔那样创建具有不同 FP 配置的 Zen 5 变体，客户端 SKU 在矢量 FP 吞吐量上花费更少的面积和功率。

Zen 4 上处理 512 位存储的效率较低，因为存储队列只能保存每个条目的 256 位待处理存储数据。在 Hot Chips 2023 上，AMD 表示缓冲 512 位存储数据的区域开销是不可接受的。泄露的 Zen 5 幻灯片上写着“加载/存储队列（512 位）”，因此 AMD 可能已经改变了立场。

由于这些变化，大量利用 512 位向量的应用程序应该会在 Zen 5 上看到更多的性能提升。

最后的话

从泄露的幻灯片来看，AMD 在通过前几代 Zen 获得了大部分唾手可得的成果后，正在追求收益递减。与 Zen 1 相比，Zen 2 大大提高了分支预测精度、向量吞吐量和缓存容量。Zen 3 改进的 BTB 设置缓解了 Zen 2 的前端延迟问题，并且重新组织的调度程序避免了 Zen 2 的 AGU 调度程序填满的情况。Zen 4 带来了更大的微操作缓存、改进的 L2 容量、大幅增加的乱序执行窗口以及 AVX-512 支持。Zen 5 似乎通过增加核心吞吐量和提供更强大的 AVX-512 实现来追求更有限的收益。

也就是说，我认为不要对当前的泄密事件进行过深入的的研究，因为具体细节很少，因此留下了很大的回旋余地。假设 Zen 5 在这一点上已经一成不变也是危险的。可以通过微代码更新来调整核心行为。核心也可以配置，这使得 AMD 即使在架构“完整”时也有可能进行重大更改。我们已经看到 AMD 推出了具有不同 FPU 配置的 Zen 2 变体。在同一视频中，MLiD 展示了另一张幻灯片，表明还存在不同的 FP-512 变体。

任何性能数据都应该持保留态度。此时最好假设它们都是猜测。即使泄密者有“来源”，估计性能本质上也很困难，因为不同的应用程序会有不同的行为。工程师可能会在具有特定指令跟踪的模拟中看到 IPC 指令提升 30%，但这并不意味着其他应用程序将享受相同的改进。

可以向泄密者提及这一点，但泄密者不明白该跟踪可能无法代表大多数应用程序。

最后，Intel、AMD、Arm 等公司的工程师在他们的产品中投入了大量的心血。当产品发布时让他们发表意见才是公平的。如果工程师发布了一款可靠的产品，可以提供典型的 10-20% 的代际增益，但每个人的看法都是基于捏造或误解的早期性能数据，我认为这是对工程师的不尊重。当英特尔在 2010 年代初期在其游戏行业的巅峰时期提供逐代收益时，这也是荒谬的。

AMD 很容易出现这种情况，因为他们是一个追赶者，人们期望能够超越更大的竞争对手，因此奇特的谣言会引起很多关注。每当 Zen 5 推出时，我都会鼓励大家根据英特尔和其他 CPU 制造商的进展来看待它的性能，而不是基于谣言。

参考链接

https://chipsandcheese.com/2023/10/07/zen-5s-leaked-slides/