说到技术上的深入探讨，我们将对 Zen 4 的报道分为两部分。 这部分将重点介绍无序执行引擎的前端和部分。 我们将在另一篇文章中从数据方面介绍内存子系统，以及 AVX-512。

概述和框图

从 1000 英尺高处看，Zen 4 看起来很像 Zen 3，但升级分散在整个管道中。 我们可以将 Zen 4 的情况与 Zen 2 的情况进行比较。 在这两种情况下，AMD 在将其移植到新的工艺节点的同时，都在发展一个坚实的架构。

迁移到新的流程节点涉及工作量和风险。 英特尔通过众所周知的“Tick-Tock”策略降低了这种风险。 每个“Tick”代表一个主要的微架构更改，而每个“Tock”是一个新进程节点的端口，具有非常小的更改。 与 2010 年代初的英特尔不同，AMD 大约需要两年时间才能迁移到新的工艺节点。 Zen 2 于 2019 年中期问世，距 Zen 1 于 2017 年初发布大约两年后，从 14 nm 升级到 7 nm。 Zen 4 于 2022 年末发布，距 Zen 3 于 2020 年末发布大约两年，并从 7 nm 移动到 5 nm。 因此，AMD 的策略最好被描述为“Tick-Nothing-TickTock”。

这是 Zen 3 的比较：

因为数据是公开的，所以为 Zen 3 绘制了更多的执行单元，而为 Zen 4 测试所有这些需要太长时间

前端：分支预测器

CPU 的分支预测器负责将管道引导到正确的方向。 准确的分支预测器将减少浪费的工作，从而提高性能和电源效率。 随着 CPU 增加其重新排序能力，分支预测的准确性变得更加重要，因为在错误预测的分支之后排队的任何工作都是无用的。

方向预测

与 Zen 系列中的其他 CPU 一样，Zen 4 的方向预测器有两个覆盖级别。 制作一个既非常快速又非常准确的预测器可能具有挑战性，因此设计人员通常必须在速度和准确性之间进行权衡。 压倒一切的预测器试图通过速度优化的 L1 预测器和准确度优化的 L2 来实现两全其美，如果预测不一致，它会覆盖它。

Zen 4 和 Zen 3 似乎具有类似功能的 L1 预测器，但 AMD 显着增强了 Zen 4 的 L2 预测器。 Zen 3 的第二级预测器已经毫不逊色，但 Zen 4 将事情提升到了一个新的水平。 它可以识别极长的模式，并且有足够的存储空间来很好地执行，即使有很多分支在运行。

左边是Zen 4，右边是Zen 3

英特尔的 Golden Cove 采取了不同的方法。 与早期的英特尔大内核一样，它使用单级方向预测器。 Golden Cove 的模式识别能力介于 Zen 4 的 L1 和 L2 预测器之间。

左边是 Zen 4，右边是 Golden Cove。 两者的分支数都高达 512，但 Excel 不喜欢标记轴上的每个点。

Golden Cove 可能会在难度适中的分支中享有优势，可以由其预测器处理，但不能由 AMD 的 L1 预测器处理。 然后，Zen 4 将失去 L2 覆盖的前端带宽。 如果一个程序有很多难以预测的分支，Zen 4 将具有显着的优势； Golden Cove 将遭受更昂贵的错误预测。 在 Golden Cove 上，错误预测的代价可能特别高，它依赖于保持更多指令在运行中以应对其更高的缓存延迟。 如果您遭受错误预测并最终将它们丢弃，那么在您的核心中跟踪大量指令将无济于事。

分支目标跟踪

有一个准确的分支预测器很好，但速度也很重要。 您不希望过于频繁地停止管道，因为您正在等待分支预测器提供下一个提取目标。 与 Zen 3 一样，Zen 4 具有两级分支目标缓冲区 (BTB) 设置，第一级非常大且速度快。 Zen 3 的 L1 BTB 可以跟踪 1024 个分支目标并以 1 个周期延迟处理它们，这意味着如果目标来自 L1 BTB，则前端不需要在执行分支后停止。 Zen 4 的 L1 BTB 保持相同的 1 个周期延迟，但提高了容量。 根据分支密度，Zen 4 的 L1 BTB 最多可以跟踪 3072 个分支目标，但实际上它可能能够跟踪 1024 到 2048 个目标。

我们已经看到 网上 声称 Zen 4 具有 1.5K 入口 L1 BTB。 在我们的测试中，Zen 4 可能偶尔能够在每个 BTB 条目中存储两个分支目标。 先前 Zen CPU 的优化手册详细介绍了此机制。

如果分支位于同一个 64 字节对齐的高速缓存行中并且第一个分支是条件分支，则每个 BTB 条目最多可以容纳两个分支。

AMD 系列 17h 处理器的软件优化指南

我们的测试在以前的 Zen CPU 上没有显示这种行为，因为我们只使用了无条件分支。 Zen 4 可能使 BTB 条目共享方案更加灵活，解释了当分支间隔为 8 个字节时我们如何看到跟踪的 3072 个分支目标。

Zen 4 的 L2 BTB 大小也略有增加，容量从 Zen 3 上的 6656 个条目增加到 Zen 4 上的 8192 个。更重要的是，Zen 4 的 L2 BTB 更快：Zen 3 在需要分支目标时遭受了三个周期的惩罚来自其 L2 BTB。 Zen 4 将这个惩罚降低到一个周期。

英特尔的 Golden Cove 具有更复杂的三层 BTB 设置。 如果您考虑 GLC 每个周期执行两个已采取分支的能力，您甚至可以将其算作四个级别。 与 Zen 4 相比，Golden Cove 对于具有 128 个或更少分支的小分支足迹会更快。 Zen 4 将拥有更多分支的优势，直到其 8K L2 BTB 容量被超过，之后 Golden Cove 更大的最后一级 BTB 应该会再次领先英特尔。

间接分支预测

间接分支可以到达多个目标。 将它们视为实现 switch-case 语句的选项。 它们为分支预测增加了另一个难度维度，因为预测器必须在几个可能的目标之间进行选择。 AMD 的 CPU 有一个单独的间接目标数组，用于处理指向多个目标的分支。 在我们的测试中，Zen 4 似乎能够跟踪多达 3072 个分支目标而没有明显的损失。 对于单个分支，Zen 4 看到随着目标数量超过 32 个而增加惩罚，但此后没有明显的飙升表明预测错误。

左边是Zen 4，右边是Zen 3

相比 Zen 3，Zen 4 对间接分支的追踪能力显然更好。 从间接目标数组中获取目标的惩罚也较低。

Zen 4 在有很多间接分支的情况下比 Golden Cove 做得更好，但是当少数分支到达很多目标时，Golden Cove 可以更好地应对。 当必须在大量目标之间进行选择时，两种架构似乎都会受到某种惩罚，但分支的行为仍在预测器的跟踪能力范围内。

一种猜测是 Zen 4 有一个更大但更慢的间接目标数组。 前几代 Zen 的优化手册表明，间接目标数组可用作压倒一切的预测器。 如果分支碰巧去了上次去的同一个地方，Zen 可以使用其更快的主 BTB 来提供目标，这意味着间接分支的延迟与其拥有的目标数量相关联。 随着 Golden Cove 上目标数量的增加，我们看到分支延迟的增加较少，这表明英特尔正在使用不同的机制。

回报预测

调用和返回对是间接分支的一种特殊情况，因为返回通常会返回到调用函数的位置。 CPU 使用特殊的返回堆栈来利用此行为。 在调用时，CPU 将下一条连续指令的地址压入堆栈。 当有返回时，它会从返回堆栈中弹出地址。 这种非常简单的机制为返回提供了非常准确的预测，因为调用和返回对通常是匹配的。 但是，非常深的调用序列可能会溢出堆栈。

与前几代 Zen 一样，Zen 4 有一个包含 32 个条目的返回堆栈。 不过，AMD 似乎做了一些改进，使得单个线程可以使用所有 32 个条目。 英特尔的 Golden Cove 可能有一个返回堆栈，因为这是一种预测返回的有效方法，但与此处测试的其他 CPU 不同。 当调用只有两个深度时速度非常快，但随后会减慢并且之后每个调用/返回对的时间不会急剧增加。 如果返回堆栈溢出，英特尔可能会顺利过渡到在返回上使用其间接预测器。

前端：获取带宽

一旦分支预测器确定下一步要去哪里，就该获取指令了。 Zen 4 与前几代 Zen 一样，可以通过大型微操作缓存加速这一过程。 与 Zen 3 相比，Zen 4 将微操作缓存的大小从 4K 增加到 6.75K 条目。 我们对 8B NOP 的测试并没有显示出微操作缓存容量增加太多，因为在 32 KB 之后获取带宽会下降。 L1i 很可能包含微操作缓存。

除了微操作缓存和 L1i 之外，指令获取带宽下降但仍然非常不错。 Zen 4、Zen 3 和 Golden Cove 都可以从 L2 每个周期维持大约 16 个字节，从 L3 每个周期可以维持略高于 10 个字节。 这应该足以防止除了具有大指令占用空间的最高 IPC 代码之外的所有指令带宽瓶颈，因为即使在矢量化代码中，平均指令长度通常也低于 8 个字节。

开玩笑吧

为了使微基准测试复杂化，Zen 4 似乎成对处理 NOP， 就像Graviton 3 一样。 我们每个周期从微操作缓存中获得了荒谬的 12 个 NOP。 AMD 表示，微操作缓存每个周期提供 9 个操作，但吞吐量受到下游 6 宽重命名器的限制。 可能发生的情况是每个重命名器插槽每个周期可以处理两个 NOP。 为了解决这个问题，我们使用了一条指令，将寄存器与自身进行异或。 将寄存器与自身进行异或是一种将寄存器归零的常用方法，大多数重命名器都会消除这种情况。

不能再访问金湾了，所以冰湖可以

另请注意，图表在 Y 轴上有一个错误，它应该是 IPC 而不是每周期字节数

但重要的部分是，XOR r,r 的行为就像一条正常指令，一直到重命名器。 我们现在还可以看到微操作缓存和 L1i 吞吐量之间的差异。 一旦 Zen 4 错过 op 缓存，吞吐量就会受到 4-wide 解码器的限制。 与前几代 Zen 一样，L1i 可能比较低的缓存级别提供更多的指令获取带宽。 但是 Zen 4 的运算缓存的大小意味着它可能可以处理需要大量指令带宽的大多数情况。 如果一个程序有足够大的代码足迹溢出操作缓存，并且有很多长指令，它也可能会溢出 L1i。

重命名/分配

在无序执行的 CPU 上，重命名器充当有序前端和无序后端之间的桥梁。 它的主要工作是分配后端资源以跟踪运行中的操作，以便它们可以按程序顺序正确提交。 重命名器也是一个方便的地方，可以拉一袋花样，使后端操作更高效。 Zen 4 的重命名器能够打破归零习语和注册 MOV 之间的依赖关系，其行为与 Zen 3 非常相似。

Zen 4 工控机 Zen 3 工控机 Zen 2 工控机 金湾IPC Sunny Cove IPC 从属 MOV r,r 5.71 5.72 4.54 5.62 4.76 独立 MOV r,r 5.73 5.7 4.55 5.68 4.77 使用 XOR r,r 的零整数寄存器 5.73 5.72 3.63

仍在使用的 ALU 管道 5.73 4.77 使用 MOV r, 0 的零整数寄存器 3.77

仍在使用的 ALU 管道 3.81 3.64

仍在使用的 ALU 管道 5.64 3.81

仍在使用的 ALU 管道 零整数寄存器通过从自身减去它 5.71 5.7 3.64

仍在使用的 ALU 管道 5.73 4.77 从属 MOV xmm, xmm 5.73 5.00 4.01

受限于 FP/vector 端的分配率？ 未测试 4.06

消除有时会失败？ 独立MOV xmm,xmm 5.71 5.71 3.84 未测试 4.77 使用 xorps 的零向量寄存器 4.00 4.00 4.00 未测试 4.76 使用 subps 的零向量寄存器 5.73 5.71 3.51 未测试 4.77 依赖添加立即 1.00 1.00 1.00 5.61 1.00

Golden Cove 的重命名器功能稍强一些，也可以消除 MOV r,0 情况。 它还可以在不使用下游 ALU 的情况下处理添加小的立即数（指令中提供的值，而不是来自寄存器的值）。

更名技巧可以更进一步，通过不为这些情况分配寄存器来节省后端资源。 消除的 MOV 可以通过将多个架构寄存器指向同一个物理寄存器来处理，这意味着不必为此类 MOV 分配额外的物理寄存器。 如果重命名器知道寄存器的值必须为零，它可以通过在寄存器别名表中设置一个位而不是分配一个实整数寄存器来记住这一点。 Zen 4 的重命名器也是这样做的，它继承了前几代 Zen 的特点，尤其是 Zen 3。

禅4 禅3 禅2 Sunny Cove（冰湖服务器） 具有 XOR r,r 的零整数寄存器 没有分配寄存器 没有分配寄存器 INT寄存器消耗 没有分配寄存器 使用 XORPS r,r 的零 128 位 SSE (xmm) 寄存器 消耗的向量寄存器 消耗的向量寄存器 没有分配寄存器 没有分配寄存器 带有 SUBPS r,r 的零 128 位 SSE (xmm) 寄存器 消耗的向量寄存器 消耗的向量寄存器 没有分配寄存器 没有分配寄存器 使用 VXORPS r,r 的零 256 位 AVX (ymm) 寄存器 没有分配寄存器 没有分配寄存器 没有分配寄存器 没有分配寄存器 使用 VXORPS r,r 的零 512 位 AVX-512 (zmm​​) 寄存器 没有分配寄存器 不适用 不适用 没有分配寄存器

在大多数情况下，Zen 4 可以避免在识别归零习惯时分配物理寄存器。 但是，128 位 XMM 寄存器是一个例外。 从 Zen 3 开始，使用 XORPS 或 SUBPS 将 1 归零会占用一个向量寄存器。 这有点令人惊讶，因为 Zen 2 在这些情况下可以避免寄存器分配。 也许 Zen 2 独立跟踪其 256 位向量寄存器的 128 位一半，但 Zen 3 和 Zen 4 以 256 位粒度进行跟踪。 在测试序列之前执行 VZEROUPPER 指令没有任何区别。

在我们测试的所有情况下，英特尔都可以避免分配寄存器，而且这种能力至少可以追溯到 Skylake。 即使在 2022 年，AMD 仍在迎头赶上，尽管这些都是相对次要的细节。

乱序资源

与前几代 Zen 一样，Zen 4 对无序缓冲区大小进行了增量改进。 结构大小的变化范围从 ROB 容量增加 25% 到存储队列完全没有变化。 对于发生变化的结构，条目数通常会增加 10-20%。 总的来说，这些变化比我们看到的从 Zen 1 到 Zen 2 的变化要大一些。

禅4 禅3 金湾 注释 重新排序缓冲区 320 256 512 Zen 4 上的每个条目可以容纳 4 个 NOP。 使用混合指令确认的实际容量 整数寄存器文件 224 192 280 标志注册文件 238 122 绑定到整数寄存器 AMD 开始在 Zen 3 中单独重命名标志寄存器 FP/向量寄存器文件 192 160 332 Zen 4 将向量寄存器扩展至 512 位 AVX-512 掩码寄存器文件 52 测量 + 16 非投机 不适用 （152 通过 MMX 测量） 自 SKL 以来，英特尔将一个射频用于 MMX/x87 和 AVX-512 掩码寄存器

但是 Golden Cove 并未正式支持 AVX-512 加载队列 88（实测 136） 72（实测 116） 192 与 AMD 的文档和幻灯片所建议的相比，所有 Zen 代的运行负载都更多。 Intel 和 AMD 有不同的加载队列实现 存储队列 64 64 114 Zen 4 有点小，很高兴在这里看到增加 分支订单缓冲区 第62话

118 没拍 48 采取

117 没拍 128

与其主要的英特尔竞争对手相比，Zen 4 在重新排序能力方面仍然是一个相当小的核心。 许多关键建筑甚至比 Sunny Cove 的还要小，更不用说 Golden Cove 的了。 但正如我们在 Golden Cove 文章 中指出的那样，英特尔需要更多的重新排序能力来处理其更高延迟的缓存设置。

在某些领域，Zen 4 的冲击力也比其标题重新排序缓冲区容量所暗示的要大一些。 我们测量了 202 个整数寄存器（共 224 个）可用于保存推测结果，覆盖了 ROB 容量的 63%。 在 Golden Cove，我们测量了大约 242 个整数寄存器，即 ROB 容量的 47.2%。 因此，Golden Cove 的重新排序能力更有可能因缺少整数寄存器而受到限制，而且情况更糟，因为 Golden Cove 在使用其物理寄存器文件时似乎效率较低。 对于 Zen 4，测得的 202 个整数加法的重新排序容量意味着使用 22 个物理整数寄存器来保存非推测结果。 假设英特尔没有减少 Sunny Cove 和 Golden Cove 之间的整数寄存器文件大小，我们对 242 个整数寄存器的测量结果意味着 38 个不能用于保存推测结果。

Zen 4 的重新排序缓冲区也很特别，因为每个条目最多可以容纳 4 个 NOP。 解码器可能会融合成对的 NOP，并且在重命名阶段再次融合成对的 NOP。 虽然这不太可能对实际代码产生重大影响，但测量 1265 个 NOP 的重新排序能力很有趣。 我们使用了一个自定义测试，最多包含 128 个整数加法、128 个浮点加法、40 个存储和 55 个分支（按此顺序），以确认 AMD 公布的 320 条目 ROB 容量。

调度和执行

调度程序和执行管道布局与 Zen 3 相比没有变化。Zen 3 的调度程序设置是 Zen 2 的重大升级，通过在 ALU 和 AGU 端口之间共享调度队列，在整数方面提供了很大的灵活性。 在浮点和向量执行方面，Zen 3 和 Zen 4 保留了前几代 Zen 中发现的大型非调度队列，但从统一的四端口调度器转移到两个三端口调度器。 在实践中，这应该很像一个统一的调度器，因为两个调度器都有类似的管道连接到它们。

调度器结构在功率和面积方面往往很昂贵。 调度队列可能必须在每个周期检查每个条目，以查看它是否已准备好执行。 为了使事情变得更加困难，它必须能够在标记为就绪的同一周期发送执行指令。 即使延迟一个周期也会导致 毁灭性的 10% IPC 下降 ，这一切都是由其本身造成的。 所有这些都变得越来越难在高时钟下实现。

AMD 可能选择专注于提高时钟速度，而不是提高调度程序的容量。 增加调度队列大小会导致收益递减。 另一方面，性能通常与时钟速度非常吻合。 也就是说，只要您的缓存设置足以防止内存瓶颈，IPC 通常不会随着时钟速度的增加而出现太大的下降。 AMD 的工程师可能看到，通过在更高的时钟频率下运行内核，他们可以获得更大的整体性能提升，而不是通过加强调度程序设置来增加 IPC。

AVX-512 实施

Zen 4 是第一个实现 AVX-512 指令集扩展的 AMD 架构。 正如我们在 Gigabyte 泄漏 的报道中所指出的，Zen 4 在 AVX-512 功能支持方面与 Ice Lake 差不多。 在实现方面，Zen 4 旨在实现 Centaur CNS 和英特尔服务器芯片之间的功率、面积和性能平衡。

AMD 在 AVX-512 上的幻灯片

AMD 通过将向量解码为两个微操作来支持更长的向量长度的悠久传统。 Bulldozer 通过将 256 位操作分解为两个 128 位微操作来支持 AVX。 K8 也做了同样的事情，将 128 位 SSE 操作分解为两个 64 位操作。 这种策略让 AMD 能够以极少的功耗和面积开销支持新的指令集扩展，但也意味着当应用程序确实利用更广泛的向量时，它们并没有太多好处。 相比之下，英特尔在 Sandy Bridge 推出时带来了全幅 AVX 执行。 Server Skylake 对 AVX-512 做了同样的事情。

Zen 4 部分打破了这一传统，将在 512 位向量上运行的指令作为一个微操作保留在大部分流水线中。 因此，每条 AVX-512 指令仅消耗相关无序执行缓冲区中的一个条目。 我假设它们在进入 256 位执行管道后被分解为两个操作，这意味着指令在管道中尽可能晚地分成两个 256 位半。 我还假设这就是 AMD 的“双抽”所指的。 与 Bulldozer 和 K8 的方法相比，这是一个巨大的优势。 为每条 256 位或 128 位指令跟踪两个微操作意味着那些较旧的架构无法使用更宽的向量来保持更多的工作。 然而，Zen 4 的方法在面积和功耗方面稍贵一些，因为向量寄存器被扩展为 512 位宽。

512 位存储是该规则的一个例外。 它们仍然被解码为两个微操作，这意味着它们消耗了两个有价值的存储队列条目。 存储队列可能是一个非常热门的结构，特别是因为存储必须留在那里直到退休，因为只有已知良好的数据才能提交到缓存。 AMD 的存储队列比 Intel 的要小很多，因此如果 Zen 4 的 AVX-512 实施存在一个严重缺陷，那就是存储的处理方式。

这可能是因为 AMD 没有为 L1 数据缓存实现更宽的总线。 Zen 4 的 L1D 每个周期可以处理两个 256 位加载和一个 256 位存储，这意味着向量加载/存储带宽与 Zen 2 保持不变。技嘉泄漏建议对齐更改为 512 位，但这显然不是申请门店。

矢量执行资源的简化框图

轻微错误，在 Zen 4 执行图上，置换通道在 FP1 和 FP2 管道上； 对于那个很抱歉

自 Zen 2 以来，最常见操作的向量执行吞吐量也基本没有变化，Zen 2 是第一个带来全宽度 AVX 执行的 AMD 架构。 Zen 2、3 和 4 都有两个 256 位 FMA 单元和四个 256 位 ALU。 起初，这似乎并不令人兴奋。 但在很多工作负载中，提供执行单元比拥有大量执行单元更重要。 与英特尔相比，Zen 4 已经具有具有竞争力的矢量吞吐量。 除非我们查看其架构的服务器变体，否则英特尔并没有显着的吞吐量优势，它们在端口 5 上有一个额外的 512 位 FMA 单元。

Zen 4 工控机 虎湖工控机 级联湖 IPC 256 位 FMA 1.90 1.99 1.94 512 位 FMA 1.00 0.94 1.82 512 位向量整数加法 1.78 1.89 1.94 1:1 混合 256 位和 512 位 FMA 1.34 0.94 1.82 2:1 混合 256 位和 512 位 FMA 1.50 0.94 1.82

各种操作的执行吞吐量

虽然英特尔的客户端架构具有与 Zen 4 相当的向量吞吐量，但通过 256 位管道的 512 位操作的处理方式不同。 英特尔在端口 0 和 1 上融合了两个 256 位单元来处理 512 位操作。 当将 256 位 FMA 指令与 512 位指令混合时，这会导致一些有趣的特性。 Intel 卡在每个周期一个向量操作，可能是因为端口 0 和 1 上的 256 位 FMA 单元必须设置为 1×512 位或 2×256 位模式，但不能同时处于两种模式。

AVX-512 还允许通过一组 K（屏蔽）寄存器屏蔽大多数操作。 为了处理这个问题，Zen 4 添加了一个相对较小的掩码寄存器文件。 掩码寄存器有大约 52 个重命名，这个寄存器文件比我们在 Skylake-X 或 Ice Lake 上看到的要小得多。 在最大重排量方面，Zen 4 比 Skylake-X 更接近 Ice Lake，因此 AMD 并没有对这个结构给予太多重视。 总结各种 AVX-512 实施决策：

类别 禅4 英特尔 Ice Lake（客户端） 英特尔冰湖（服务器） 半人马中枢神经系统 注释 执行 512 位操作 512-bit ops进入执行管道后拆分成2×256-bit 端口 0 和 1 上的 256 位单元融合以处理 512 位操作。 端口 5 有 512 位整数 ALU，但没有 FMA 端口 0 和 1 上的端口融合，以及端口 5 上的专用 512 位 FMA 和 ALU 解码为 2×256 位操作 Zen 4 几乎等同于英特尔 再订货能力 512 位指令作为一个操作跟踪

512 位存储分为两个 512 位指令作为一个操作保存 512 位指令作为一个操作保存 作为两个微操作跟踪的 512 位指令 Zen 4 与 Intel 大致相当，除了 512 位存储 屏蔽寄存器 掩码寄存器的 52 次重命名 假设与服务器变体相同 136 次重命名掩码寄存器 别名为标量整数寄存器文件 不如英特尔，但优于 CNS 非常便宜的实现，后者会引起对热资源的争用 加载/存储 每个周期 1×512 位加载，

每 2 个周期 1 个 512 位存储 每个周期 2×512 位加载，1×512 位存储 每个周期 2×512 位加载，1×512 位存储 每个周期 1×512 位加载，1×512 位存储 英特尔的显着优势

Zen 4 从 AVX-512 获得了比 Centaur CNS 更大的收益，后者以最小的裸片面积开销实现 AVX-512 支持。 反过来，英特尔看到了比 Zen 4 更大的收益。启用 AVX-512 的 Golden Cove 在此基准测试中实际上在扩展和绝对性能方面都优于 Zen 4。 但这可能是这一代人的争论点，因为英特尔无法在其混合客户端芯片中启用 AVX-512 支持。

结果 Daniel Lemire 的整数到字符串转换基准的 ，它利用了新的 AVX-512 指令

总而言之，AMD 的 AVX-512 实施侧重于更好地满足现有执行能力，并且只在其产生最大影响的地方使用额外的芯片面积和功率。 最昂贵的更改可能与扩展向量寄存器文件以使每个寄存器为 512 位宽有关。 AMD 还必须在整个流水线中添加掩码寄存器文件和其他逻辑来处理新指令。 与 Intel 的客户端实现一样，AMD 避免添加额外的浮点执行单元，这会很昂贵。 与 Intel 不同的是，AMD 也保持 L1D 和 L2 带宽不变，并将 512 位存储拆分为两个操作。

结果是非常可信的第一轮 AVX-512 实施。 与 Intel 相比，AMD 在一些关键领域仍然存在不足，如果 AVX-512 代码需要大量加载/存储带宽并适合核心专用缓存，则尤其处于劣势。 但是，虽然 Zen 4 的目标没有英特尔那么高，但它仍然可以从 AVX-512 中以与客户端英特尔架构相同的许多方式受益。 AMD 对 512 位向量的支持也强于最初在 K8 Athlon 中对 128 位向量的支持，或者从 Bulldozer 到 Zen 1 的 256 位向量。Zen 4 在可以利用 AVX-512 的应用程序中应该会看到明显的好处，无需花费大量功率或模具面积。

第 1 部分结论

Zen 4 引入了大量的前端和执行引擎改进。 分支预测器和微操作缓存改进让前端更快地将指令带入核心，并建立在 Zen 3 已经强大的前端之上。 后端增加的重新排序能力让 Zen 4 更好地吸收缓存和执行延迟。

然而，AMD 几乎没有改变执行单元和调度程序的设置。 执行单元没什么大不了的，因为 Zen 3 已经有足够的执行能力了，提供执行单元比增加更多更重要。 然而，没有增加任何调度队列有点令人惊讶。 AMD 提高了调度能力，并且在之前的每一代 Zen 中至少对调度器布局进行了微小的更改。 Zen 3 在灵活的布局中已经具备了充足的调度能力，因此 Zen 4 的相同设置无论如何也不弱。 但随着其他组件的改进，调度能力可能会成为更多的限制因素。 Zen 4 通常会在整数代码方面表现出色，尽管 IPC 的增加在时钟速度提升方面处于次要地位。

Zen 4 在加载和存储带宽方面也落后了。 它的 L1D 每个周期可以提供 512 位的加载带宽和 256 位的存储带宽。 这使得 Zen 4 的 L1D 带宽与 AMD 方面的 Zen 2 和 Zen 3 或英特尔方面的 Haswell 和客户端 Skylake 保持一致。 Zen 4 在使用 256 位向量（或更小）的代码方面仍然表现出色，尽管可能达不到 Golden Cove 的水平。

但是，AMD 在支持 AVX-512 方面拥有优势。 如果代码使用新的 AVX-512 指令和功能，这些指令和功能在 Zen 4 上具有优化的路径，但没有直接的 AVX2 等效项，英特尔将发现自己处于不利的不利地位。 Zen 4 可能没有全面的 AVX-512 实施。 但如果应用正确，它仍然足以击败缺乏 AVX-512 支持的竞争对手。

当然，这假设两个处理器都没有受到内存子系统的瓶颈。 在线程良好的矢量化应用程序中，缓存和内存性能可能非常重要。 这是一个复杂的话题，我们将在 后续文章 中介绍 Zen 4 的加载/存储子系统和数据端内存层次结构。

如果您喜欢我们的文章和新闻，并且想支持我们的努力，那么 考虑前往我们的Patreon 或我们的 PayPal 如果您想向我们扔几块钱，或者如果您想与 Chips and Cheese 工作人员交谈，请 然后幕后的人考虑加入我们的 Discord 。