以下内容转自本人知乎专栏首发。

https://zhuanlan.zhihu.com/p/274750946

新纪元

自从 Zen 架构系列处置惩罚器推出以来，AMD 出奇的顺风顺水，这不但体现在强大的产物力上，而且连对手也都似乎有点发焉了，英特尔制程严重停摆，给人的感觉英特尔几乎就靠微架构技术积累这口仙气吊命，而 Zen 这边每代架构的提升都相当明显。

例如 Zen 2 引入了更快的向量指令实现、更先进的制程，目前在英特尔传统优势项目——笔电领域已经打了翻身仗，英特尔服务器、笔电、台式的三驾马车产物组合已经全部马失前蹄。

英特尔这边也不是说没有动作，前不久发布的 Tiger Lake 系列就有比力精彩的性能体现而整体平台优势，奈何这个产物是面向笔电领域，它的情况有点像当年英特尔的 Yonah，给人一种远水救不了近火的感觉。

然而，和当年差别 K8 世代的是，如今的 AMD 的 Zen 架构在产物力上具有更强的侵略性了。

整个 PC 市场不再如 10 年前那样蓬勃，市场已经步入萎缩，当 AMD 急速上升的时候，Intel 不能再像当年那样透过鼎力大举拓展笔电、服务器等市场来缓解台式机阵地的沦陷。而笔电和服务器领域，现在 AMD 也已经开始重新步入正轨，Zen 架构有明确的路线图，新产物不太可能再现当年 K10 到 Bulldozer 那样的性能逆生长情况。

固然，Zen 也不是说毫无缺点，它与生俱来的一个巨大问题出于本钱原因接纳了片上 NUMA，随之而来的问题自然是 Zen、Zen2 虽然外貌看上去是很美的 8 核处置惩罚器，但是实际上是两组 4 核处置惩罚器，当出现需要较大容量 L3 Cache 应用的时候，这种设计就容易袒露出性能显著下降的问题。

这种众所周知的事情，AMD 心里自然也很清楚，经过两代半产物（Zen1、Zen+、Zen2）的迭代后，这个问题的解决方案终于被摆上台面，这正是 AMD 新发布的 Zen 3 微架构，也是本文的主角。

这篇测试主要围绕是微架构部门：Zen 3 的微架构和前一代相比有哪些重大变革，这些变革对单元时间性能（IPC）有什么影响。

Zen 3 的点点滴滴——从指令集说起

随着条记本这边的 Zen2 产物线命名为 Ryzen 4000 系列后，Ryzen 5000 系列也就自然而然的成为了 Zen 3 的产物型号了。

第一波的 Zen 3 主要针对高端产物，它们分别是 Ryzen 7 5800X、Ryzen 9 5900X、Ryzen 9 5900X，别的还有针对中高端的 Ryzen 5 5600X，先放个简单的对比表：

对于 AMD 来说，Ryzen 5000 系列的主要任务与 Intel 的十系列（内核步进代号 CometLake）台式处置惩罚器竞争，因此其性能必须到达相当甚至更好的水平。

CometLake 的最高端产物为 Core i9 10900K，微架构可以追溯至 5 年前（2015 年 8 月）的 SkyLake（各编译器里 CometLake 对应的微架构旗标就是 skylake），属于 SkyLake 的第七版步进，Zen 3面对的就是这个潜力一挖再挖的微架构，最初接纳 Skylake 的产物被称作第六代 Core（酷睿），是十系列四代之前的产物了。

SkyLake 微架构发展：SkyLake->KabyLake->CoffeeLake->AmberLake->WhiskeyLake->CoffeeLake 更新->CometLake

而在 Zen 3 这边 AMD 较早之前给开源编译器组织 CNU 和 LLVM 递交了名为 znver3 的编译器开关，其中有若干条新指令。

首先是目前 Intel 并未公开支持的：

然后是 Intel 目前已经支持的：

其中对性能有影响的主要是前面的 5 条指令，不外目前最新的 GCC 正式版 10.2 并未提供 znver3 旗标，GNU 这边需要到明年正式发布的 GCC 11.0 才会提供，LLVM 则需要 12.0。

换而言之，除非是使用汇编代码，目前的 GCC/Clang 编译器只能使用 znver2 来编译，在 Zen 3 上会有轻微的性能发挥问题，这些零星的新指令算不上重要的扩展。行文至此，AMD 自己的 AOCC 编译器依然停留在 2.2 版（基于 Clang 10 和旧 Flang 的 AMD 官方优化版）。

从 CometLake 可以看出，如果没有什么重要的改动，编译器一般不会去增加微架构旗标，包罗 Intel 自己的编译器也都没有为 SkyLake 后的架构改版增加微架构优化旗标。

而到了 AMD Zen 这边，每一代微架构基本上都有一个新的旗标对应，Zen+ 虽然没有直接的旗标，但是根据我在 Ryzen 5 3550H 的实测，它使用 znver2 跑 SPEC CPU 2006/2017 时候的性能也会有一定的性能提升。

改用新的微架构旗标有提升，说明了三件事，一个是微架构有变革，另一个是编译器方面有优化，而处置惩罚器旗标的提交都是处置惩罚器厂商自己提交的，所以 AMD 软件团队基本上是跟得上节奏的，奈何软件开发简直是一件需要考虑方方面面的事情，所以还需要时间来实现。

插播——关于 SPEC CPU 2017

本文会有大量的 CPU 2017 测试数据，为了让各人清楚这是一个什么东西，先让我在这里插一下相关的介绍，已了解的可以跳过本节。

CPU 2017 是非盈利机构 SPEC（尺度性能评估公司）推出的 CPU 性能评估套件，SPEC 建立于 1998 年，会员包罗 Intel、AMD、IBM、DELL、联想、华硕、技嘉等业界大公司，每隔约莫 10 年就会推出一版新的 CPU 性能评估套件，CPU 2017 是该机构在 2017 年推出的，是所有处置惩罚器、电脑厂商做处置惩罚器性能评估的最重要手段之一（如果不是使用上有一定门槛，上面这句话的“之一”是可以省略的）。

SPEC CPU 的特点是由各个机构提供实际应用的源码，它的每一个子项目其实都是源自真实应用修改而来，其修改主要是针对可移植性和遵循的语言尺度，例如 x264 的真实版本接纳了大量的汇编代码，但是这样的形式倒霉于移植到差别指令集架构上测试，因此CPU 2017中的 x264 接纳的是纯 C 语言版本。

和上一版本 CPU 2006 相比，CPU 2017 的代码已经全面更新，虽然依然使用 C/C++ 和 Fortran，但是相对以前的版原来说，已经酿成了多语言的大混装，Fortran 语言同时出现在浮点和整数测试集，而非像以往那样只出现在浮点测试集。

CPU 2017 的规则更加严谨，speed 测试集允许使用 OpenMP 多线程处置惩罚，主要测试较大访存压力下的单任务多线程性能，而 rate 测试集则只允许单线程，禁止自动并行化，但是允许以多任务的方式跑多个 rate 测试，目的是测试吞吐率，单个 rate 任务的访存压力要比 speed 小很多。

不外 speed 测试集也不是全部项目都支持多线程，只有浮点密集型的 fpspeed 所有项目支持多线程，整数密集型的 intspeed 10 个子项目中只有最后的 657.xz_s（数据压缩）是支持多线程的。

这样的规则让以往 CPU 2006 以及更早版本中常见的编译器自动并行化“优化”手段被禁止使用，减少了测试结果的混乱（测试如果使用了编译器自动并行化后，实际上酿成了编译器比拼），提高了可比性。

上面两个表格就是 CPU 2017 四组测试集的介绍，5 字头的都是 rate 测试、6 字头的都是 speed 测试，rate 不允许多线程或者自动并行化，但是可以同时跑多个相同实例的方式执行。speed 只有 fpspeed 是全部支持多线程，intspeed 只有 657.xz_s 支持多线程。

657.xz_s 的内存开销是 CPU 2017 单个子测试中名义最高的，根据观察起码需要 16GiB 内存，但是实际上 fpspeed 相当部门测试对内存存取非常偏好于 dual rank 内存模组配置，4 *8 = 32 GiB 内存的系统由于 dual rank 的关系跑 fpspeed 会比 2*8 = 16 GiB 内存的 single rank 系统快上一截，单看容量不一定能了解内存子系统是否能满足需求。

我这次主要使用 gcc/g++/gfortran 10.2 的 GCC 三套件外加 Jemalloc 内存分配库进行测试，接纳 GCC 而不是 ICC、AOCC、LLVM 的原因有三点：

1、GNU 这边有完整的 gfortran 实现，LLVM 那边的 Flang/F18 目前缺乏 codegen，只有语义等环节，AMD 的 AOCC 在页面介绍说是 LLVM 10，但是根据 Flang/F18 开发人员 Kiran Chandramohan 给我的回信，AOCC 的 Flang 其实是基于老 Flang（并入 LLVM 之前）的，所以 LLVM 的工具集并不完整，不适合作为我们的测试使用。GCC 的性能比比 AOCC 更快，。

2、Intel 编译器也是一个不错的选择，根据我的实测，跑起来会两边其实差不多，ICC 浮点会快一点点，整数一样。我们希望尽量公平一点，所以在区别极小的情况下，一律使用 GCC。别的，GCC 有些特性是我觉得很有用的，例如它提供了读取 native 微架构旗标时实际调用了哪些优化开关的功能。

3、GCC 10.2 和当年我初次接触 的 GCC 4 相比已经有非常巨大的进步，不管是代码生成质量还是兼容性、文档和技术支持，都让我可以有掌握排除一些测试中遇到的问题，例如 GCC 10 引入了一些优化开关的问题，经过查找文档后我自己解决，而 SPEC 那边也在稍早公布了相应的解决方案。

Zen 3 内核的提升重点——Load/Store

根据计算机科学的划分，指令集架构（ISA）定义了指令的格式和功能，而微架构（microarchtecture）定义了处置惩罚器的内部构成。

微架构一般以流程结构图的形式展现，其中会有各种路径和功能单位，例如高速指令缓存、动态分支预测器、解码器、指令调度器、逻辑计算单位、浮点计算单位、载入/生存单位、高速数据缓存以及系统总线。

现代的微架构中，内核的概念通常是根据存储条理来划分——从寄存器到 L2 Cache 这个级别的单位集成被称作“内核”，芯片中的其余部分（包罗 L3 Cache、内存控制器、系统总线）一般称之为 Uncore。这是现代方式的划分，但如果是 i386 这种“远古”时代的处置惩罚器根据官方规格连 Cache 都没有集成，需要在主板上安装昂贵的 SRAM 颗粒，这种原始物种的内核相对而言是光溜溜的。

对于微架构的改动，我们先从“内核”谈起，先放一张 AMD 提供的 Zen 3 内核微架构图：

如果光看这张图的话，大部门人也许都不知所云，不外好在 AMD 之前在开发者优化指南中提供了一份类似的 Zen 2 架构图，将两张图一起放在一起后，就可以便于了解 Zen 3 在微架构上的主要变革了：

正如你所看到的那样，从“大”的方面来说，Zen 3 相对 Zen 2 内核的主要区别是 Load/Store 性能的变革：

从 Zen 2 每周期 2 Loads + 1 Stores 提升到了 Zen 3 的每周期 3 Loads + 2 Stores，幅度分别为位 +50% 和 + 100%。

众所周知，x86 是接纳寄存器-内存（register-memory）的指令集架构，各种类型的算术指令既可以运行于寄存器也可以直接运行于内存上。不外，这是什么意思呢？

例如，x86 常见的指令类型（为了方便，我这里使用伪指令）：

add Reg_A, MemAddr_var_1;

这是一条加法指令，将内存源地址 var_1 里的值和目的寄存器 A 的值相加，计算结果存放在寄存器 A 中，同一条指令里既有寄存器，也有内存。

内存地址_var_1 指向的值可能在物理内存或者高速缓存中，如果是后者就可以显著减少访存导致的性能下降。

寄存器属于最接近计算单位的存储资源，时延一般是 0 或者 1 周期，而内存需要访存指令，时延可能会高到 100 到数百个周期以上。

这是 CISC 指令集的特点之一，与之相对应的 RISC 指令集里，运算指令的源和目的数都必须位于寄存器中，寄存器的值需要另外透过 Load/Store 指令从内存加载（Load）或者向内存（Store）生存，上面的伪指令改为 RISC 来写的话，可能就是这样了：

ldr Reg_B, MemAddr_var_1

add Reg_A, Reg_B;

固然这是指令集层面的，对于现在的 x86 处置惩罚器来说，指令中的内存访问操纵其实也是透过专门的 Load/Store 指令单位（LSU）来实现，不管哪种指令集架构，LSU 都直接影响步伐运行体现。

Load/Store 属于内存操纵，因此增加 Load/Store 单位，主要改善的是涉及内存密集型的操纵，具体得看步伐里的动态 Load/Store 指令占比，L/S 动态指令占比越高 L/S 单位性能体现影响应该越大，固然因为涉及到内存，所以 L1 D-Cache、L2 Cache、L3 Cache、硬件预拾取器、主内存以及它们的总线等也会有相应的影响。

空口无凭，各人先来看看我使用 AMD Ryzen 7 3800X 在 SPEC CPU 2017 中 INTRate（整数密集型）测试集单线程模式下实测测试时的动态指令类型分布，数据收罗源自处置惩罚器的事件计数器。

软件配置说明：SPEC CPU 2017 1.1；

编译器/ 库/操纵系统：gcc/g++/gfortran 10.2 + Jemalloc 5.2.1，Ubuntu 20.04 Kennel 5.4；

编译器主要优化旗标为 znver2、-Ofast；

我们这里先用 rate 测试集为例，提供该测试集中分支指令、L/S 指令比率和占比情况：

SPEC CPU 2017 intrate 整数测试集特性，数据接纳 CPU 厂商的性能事件计数器收罗统计：

SPEC CPU 2017 fprate 浮点数测试集特性：

（单元说明，GInst：十亿条指令；x：倍数）

正如你所看到的，在 CPU2017 中，L/S 指令的动态指令数（处置惩罚器实际执行的指令数，非编译后的二进制静态指令数）占比平均凌驾了 45%，引入更多的 L/S 单位能让处置惩罚器有效提高指令并行度。

整数和浮点测试集的 LT/ST 指令比率的几何平均值分别为 3.1x 和 4.6x，这说明 Load 单位的数量应该尽量设计为比 Store 单位更多才合理，目前大部门处置惩罚器都是如此，在 Zen 3 中这个比例是 1.5x 或者说 3:2。

值得一提的是，我们在测试 SPEC CPU 的时候接纳的 Jemalloc 是一个内存分配器。

存活的生命周期取决于函数或者所在域的生命周期），分配的内存巨细在初始化后就固定稳定的，出于性能优化的目的，如果编译器这边不设置专门的参数，其巨细一般很小，例如几十 KiB，优势是性能比力容易优化。

而动态内存则相对灵活许多，其巨细可以用变量的方式设定，

相对于 gcc/g++ 内建的内存分配器可以在一些测试中提供更精彩的内存性能。

在更早之前的 CPU20XX 系列官方测试榜单上，内存分配器基本上是 SmartHeap 的天下，smartheap 是收费的库，价格非常贵，这使得我以前跑 CPU20XX 的时候只能各种羡慕与好奇，直到后来出现了 Facebook 推出开源的 Jemalloc 后情况才有变革。微软这边也做了一个 mimalloc，据闻性能也不错，有时间再看。

AMD 的文档在前面的架构图基础上提供了更多的细节，下面根据他们提供的列表展开 Zen 3 微架构的介绍。

前端（取指、动态分支预测、解码等）

前端各工位主要设计目标：更快的指令拾取，尤其是分支类指令以及长指令，Zen 3 进行了如下改进：

L1 分支目标缓存（L1 BTB）巨细加倍到 1024 条目，实现更快的分支时延；

提升了分支预测器的带宽；

更快地从预测失误中恢复；

“不冒泡”预测能力让“背对背”预测可以更快更好地处置惩罚分支代码；

op cache 取指测序更快；

op cache 流水线的切换粒度更精细。

处置惩罚器的流水线可以分为取指、解码、执行、写回四个工位，其中前端（front-end）是指取指和解码，执行和写回被称为后端（back-end）。

对于现在的超标量流水线处置惩罚器说，每个周期可以执行多条指令，前端需要为后端提供匹配的取指、解码能力，同时为了包管流水线闲置执行单位不浪费，人们还引入了分支预测单位，根据预测结果决定是否将下一条指令先派发给后端闲置的单位执行，待分支确定是否选中后再决定是否保存计算结果或者重置流水线。

op cache 也被称作 micro-op cache 或者 L0 I-Cache，它里面存放的是若干段处置惩罚器认为会被近期重复使用的微操纵（micro-ops），所谓的微操纵是 x86 处置惩罚器为了简化后端设计引入的处置惩罚器本机指令，是已经经过解码器解码的长度固定的本机指令。

在循环语句里的指令在很多情况下都是不停重复的，这些指令以微操纵的方式放在 uop cache 后，后面重复执行这些操纵的话，就无须经过解码器这个工位，直接发往后端的队列里等候发射执行。

uop cache 在 x86 上的原型是当年 Pentium 4 引入的 Trace Cache，Trache Cache 需要消耗大量的芯片面积，但是这是提高超长流水线架构处置惩罚器性能重要的一环。在 Pentium 4 终止后，Trace Cache 的瘦身版就以 uop cache 的形式引入，AMD 在 Zen 上面也引入了该技术。

那么 Zen 3 经过上面的步伐后，对解码能力、分支预测能力以及 op cache 的实际改进如何呢？我们先来看看解码部门的实测性能。

非常有意思的测试结果。

从测试结果来看，Zen 3 在单字节指令时候的解码、执行能力到达了真正的每周期 6 指令，固然这样简单的指令可能实际意义不是很大，先看着乐吧，它至少证明了前后端的单位规模在简单指令的情况下，是可以满足每周期 6 指令的吞吐要求。

到了 8 个字节长度的指令时，虽然 Zen3 依然是只有每周期 32 字节（相当于每周期两条长度为 8 字节的 x86 指令）的解码带宽结果，但是维持每周期 32 字节的能力已经从 Zen2 时代的 15 KiB 平移到了 22 KiB 字节，这相当于 7 KiB，到达了 i7 9900K 的两倍，可能的解释是 op cache 巨细或者等效巨细增加了 7 KiB。

在更早之前，网上有一篇 AMD 美国研究院 Jagadish B. Kotra 和 John Kalamatianos 撰写的预印刷论文《Improving the Utilization of Micro-operation Caches in x86 Processors》，里面介绍的是透过减少未操纵高速缓存碎片，从而实现的微操纵高速缓存压缩，实现了性能提升。

AMD 前面提到的 uop cache切换粒度更小可能与此有关，因为类似的情况在单字节指令（NOP）中并未出现，而长字节指令更容易被压缩。固然目前还没得到官方回复的情况下，这些纯属个人推测。

接下来，让我们看看 Zen 3 在分支预测能力的变革，这里接纳 SPEC CPU2017 Intrate 来对比：

我们同样接纳处置惩罚器厂商提供的硬件事件计数器记录下三款处置惩罚器运行 SPEC CPU2017 时候的分支预测失误率数据。理论上，这个世界不可能存在完美的分支预测器，但是可以尽量接近 0% 的预测失误率。

一旦分支预测失败，流水线就会被洗刷重置，流水线有多长，就会损失与流水线工位数相当的周期数，例如流水线长度是 20 级的话，出现分支预测失败，就会至少损失掉 20 个周期的性能。也就是说，当出现一条分支指令预测失败的话，性能损失将会放大 20 倍。

假设动态指令中分支指令占比 20%，里面有 1% 的分支指令预测失败，至少要损失整体 2% 的性能，但如果其中有访存等动作，实际的性能损失可能是这个数字的 10 倍以上，例如实际整体性能可能要损失 10% 到 30%。

从测试结果来看，我们认为 Zen 3 的动态分支虽然有变更，但是整体的预测准确度和 Zen 2 差不多，Zen 2 在 549 和 554 中有更好的体现，而 Zen 3 在 511 和 538 中有较高的体现。

和 Intel 目前最新的 CometLake 相比（我们测试的是 Core i9 10900K），AMD Zen 2/Zen3 的动态分支预测准确度明显要高出不少，这里点个赞。

前端部门有了解码和分支预测性能，好像写的差不多了，不外我想这里插播一下流水线深度测试，看看 Zen 2 的流水线到底有多少个工位。

这是有原因的，它和分支预测失败导致的性能开销以及频率延伸能力有一定的关系，而 AMD 和英特尔现在都没有公布这方面的数据，这次的 Zen 3 测试指南中只是有一句模棱两可的话语：更快地从预测失误中恢复。

下表中的左侧是以伪代码方式提供分支步伐测试片段，以第 7 个测试（Test 6）为例：

Test 6, N= 1, 8 br, MOVZX XOR ; if (c & mask) { REP-N(c^=v[c-256]) } REP-2(c^=v[c-260])

这段内容包罗了一个 MOVZX 内存载入操纵指令，它需要额外的 5 到 6 个周期来执行，在支持乱序执行、乱序 L/S 的处置惩罚器中，这个动作占用的流水线工位通常会被掩盖掉。

从测试结果来看，Test 6 的 Zen 3、Zen2、Zen 1 测试结果分别是 8.21、12.22、12.30 个周期，加上 MOVZX 的 5 个周期，那这个测试的 Zen 3、Zen 2、Zen 1 有效结果就是分别是 13、17、17 个周期。

Zen 3 的等效流水线工位是 14-18 级左右，普遍减少了 4 个工位！

测试结果完全出乎我的意料——没想到 Zen 到了第三代的时候居然出现了流水线工位减少的情况，流水线工位减少，意味着分支预测失败的处罚更低，随之而来的是频率延伸能力可能更低，但是最终产物来看，Zen 3 系列的全核加速频率并不比 Zen 2 弱甚至要更快。

这说明了一点：AMD 在缩短流水线工位的同时透过优化电路、制程等步伐，实现了更高的频率。

执行引擎（重排序、指令派发、运算单位、回退等等）：

主要设计目标：降低时延、扩充单位，实现更高的指令级并行（ILP），Zen 3 作了如下的改进。

为整数操纵提供独立的分支和存储拾取单位，相对于上一代的 Zen 2 增加了三个，到达了 10 指令发射能力；

更大的整数指令窗口，相对于 Zen 2 增加了 32 条目；

降低了个别浮点和整数指令的时延；

浮点内存操纵单位增加了两个，浮点流水线派发和发射能力提升到 6 指令；

浮点 FMA 指令时延缩短了 1 个周期。

对于执行引擎，我们测试了 ReOrder Buffer、指令吞吐时延等数据。

很多乱序执行处置惩罚器都接纳了名为 Re-Order Buffer（重排序缓存）的技术，使指令在乱序执行后能够根据原来的顺序提交结果。指令在以乱序方式执行后，其结果会被存放在 ROB 中，然后会被写回到寄存器或者内存中，如果有其它指令马上需要该结果，ROB 可以直接向所需的数据。简而言之，ROB 的巨细对于确保有足够的乱序驻留指令以及动态分支预测的恢复，对提升指令集并行度有不可忽视的作用。

我这里使用 Travis Downs 的 rob size 工具来测试，测试结果如下：

正如你所看到的那样，Zen 3 的整数 ROB 巨细已经从 Zen 2 的 224 提高到了 256，这是一个不错的提升，意味着 Zen 3 能够提供多 32 条指令或者说微操纵的乱序执行能力。

现在让我们看看指令时延和吞吐的测试结果，测试数据源自 AIDA64，不外由于篇幅有限，而采样的指令数据高到 4600 项，我们只能接纳只选取若干我们认为比力重要的指令，例如赋值（mov）、位移（shift）、加法(add)、乘法（mul）、FMA、除法（div）、平方根（sqrt）以及与之对应的单精度(xxxxPS)、双精度模式（xxxxPD），别的还有 AES 等指令，测试结果以 时延|吞吐 的方式展现，单元是周期。

测试结果如下：

在 x86 中，mov和 lea 都属于赋值指令，这里测试的是寄存器赋值。其他的指令大家应该都比力熟悉，相关的文档也有介绍，例如 VPMUL 指令可以在这里找到解释。

从 Cyrix 在 95 年发布的 Cyrix M1 处置惩罚器是史上第一款具备寄存器重命名和乱序执行能力的 x86 处置惩罚器算起，x86 处置惩罚器的乱序执行至今已经有 25 年了。

在绝大部门情况下，寄存器重命名不一定和乱序执行是挂钩，例如 Intel IA64 就有多达 128 个通用整数寄存器，虽然也涉及寄存器重命名的概念，但这是编译时的事情，在编译时做寄存器重命名也不见得都是好事（容易导致代码膨胀，降低指令高速缓存命中率）。

对于 x86-64 这种只有 16 个指令集架构寄存器的指令集架构而言，寄存器重命名是保障乱序执行必不可少的技术，要重命名，自然得需要有足够的物理寄存器才行，物理寄存器越多，可供重命名的资源也就越多，维持乱序执行的能力就越强。

我们使用 robsize 同样的测试步伐进行了物理寄存器堆（PRF）大小的探测。这里说明一下，我们前面的 rob 巨细探测使用的是 nop （空操纵）指令，不占用任何寄存器，而接下来做的 PRF 巨细推测测试，使用的是 add（加法）指令。

需要注意的是，物理寄存器堆里同时含有乱序执行中可用于推测执行的推测寄存器数量和已提交寄存器数量，因此这种测试方式不能把直观地把整个物理寄存器堆的巨细给出来，它只能丈量出可用于推测执行的寄存器数量。

正如你所看到的那样，Zen 3 可用于推测执行的物理寄存器巨细要比 Zen 2 小了 16 个.

根据官方的规格，Zen 2 的物理寄存器堆巨细是 180 个，实测可用于推测执行的是 144 个，因此有 36 个不能用于推测执行。

而到了 Zen 3 上，根据官方规格是 192 个，因此在 Zen 3 上不可用于推测执行的寄存器数量应该是 64 个。

Comet Lake 预期的物理寄存器数量应该是 180 个，实测可用于推测执行的是 144 个，有 36 个物理寄存器不能用于推测执行。

再看看浮点物理寄存器的情况，我们使用 AVX 指令来探测。

三个微架构可用于推测执行的浮点物理寄存器巨细相当，都是 144 个。

三个微架构都不支持 AVX-512，所以这次就不消考虑测试 zmm/ymm 寄存器的共享问题了。

3、Load/Store 单位或者说内存子系统：

主要设计目标：扩建+更快的预拾取，以支持增强了的执行工位。

更高带宽，满足更大、更快的执行工位带宽需求；

Load 单位 +1；

Store 单位 +1；

更灵活的 L/S 操纵；

内存相依性检测能力增强；

TLB 中的页表搜索器（table walker）增加了 4 个。

我们使用 uarch-bench 做了一些 LSU 相关的测试，

正如你所看到的，Zen 3 的实测 store 性能到达了每周期两个，对于相同目标地址的加 1 内存操纵，现在只需要 1 个周期就能完成，而 Zen 2 需要 7 个周期，我相信除了增加 LSU 外，Zen 3 还有一些别的优化步伐实现这个能力。

4、SOC 架构（芯片级架构）：

主要设计目标：减少系统主内存访问，降低各内核间时延，降低内核与高速缓存的时延。AMD 认为这部门对游戏性能至关重要，尤其是游戏中常见的“Hero Thread”（主线程）会频繁访问 L3 Cache，这类游戏在 32 MB L3 上的体现会比 16MB L3 更好。

把 CCD 中所有内核统合到同一个 CCX 中；

把 CCD 中的 L3 Cache 合并为一整块 32MB；

接纳环型总线对内核和高速缓存的通信线路进行重架构。

在 Zen1 的时候，我们就第一个指出了 Zen1 存在 CCX 共享效率较低的问题，这个问题一直困扰着 Zen 这个优秀的架构。

毫无疑问，Zen 3 的这个改进对于游戏玩家来说，这是 Zen 3 最重要的变革，更大的高速缓存意味着线程共享数据导致的访存请求，不管哪个角度看，这个改进都能让各人放心地把 Zen 3 放入购物车中。

我们使用 Intel 的 Memory Latency Checker 3.9（AMD 内部也是使用这个工具）进行该测试：

Memory Latency Checker 中有一个 --c2c 的测试开关，可以用于指定测试差别内核之间进行数据交换的时延。

它提供了两种测试模式，分别是 HITM 和 HIT，我们使用的指令分别类似于以下的样子：

写入线程绑定到 1 号内核 1 上，在其 L2 cache 中对 128 KiB 的数据进行修改，然后数据传输到 0 号内核上，由于数据块处于 M 状态，因此嗅探响应会将它设定为 Hit-Modified 状态，然后数据块才会从 cache 传输到“请求者”。之后，控制权转回到做写入操纵的 1 号内核，该内核会把操纵窗口移动到参数 b 指定的缓存（巨细为 200 KiB）中的另一个 128KiB 数据块上，然后重复上述的处置惩罚至完成。

和：

类似上面的操纵，但是 1 号内核不做数据修改处置惩罚，它会绑定并读取参数 -b 指定的缓存到自己的 L2 Cache，然后将控制移交给 0 号内核做读取操纵。此时参数 -b 指定的 200KiB 数据已经被读取至 1 号内核中，其状态被设置为 E 状态，嗅探响应会被设定为 Hit-Clean（HIT），数据块会从该 cache 传输到请求者（0 号内核）里。

从我们的测试来看，Zen 2 的 L2 cache 数据交换操纵时延在 4 号到 7 号出现接近 300 个周期的时延，到了 Zen 3 这边，时延降低到了 100 周期的视频，现在的速度相当于是以前的 3 倍。

比力特别的是，Zen 3 的时延有一个特点，那就是第 0、2、4、6 号的数据交换时延是相对较快的，都在 90 周期以内（HITM 模式），然后 1、3、5、7 的时延会高一些，约莫高 6 到 17 个周期，幅度还 20 个周期。相较而言，CometLake 的内核数据共享时延基本上都在 63 到 75 周期，幅度在 12 周期。

可以这么认为，在芯片级的内核间交换时延方面，AMD 已经有长足的进步，但是和 Intel 的最新处置惩罚器相比，仍然有一点差距。

实际测试性能对比

测试平台介绍

感谢 AMD、映泰（BioStar）、华硕（ASUS）、阿斯加特（Asgard）对本工作室的鼎力大举支持，使得本次测试使用到的处理器、内存可以及时就位，如果没有这些基础硬件的来临，我现在应该会快乐地云测试。

时间有限，不多废话，放本人实拍的产物图：

阿斯加特 DDR4-3600，双条可超频至 4000，不外我们需要 32 GiB 内存，所以只上了 DDR4-3600。

映泰 B550GTA，实测下来是一块非常稳定的板子，应有尽有：

华硕 ROG Strix X570-E，其实我想要的是 Crosshair 8，但是这片实测下来也是很舒服的，开机自检速度比力快：

我这次接纳 SPEC CPU2017 进行对比，首先，我们使用同频率 4GHz 来测试，其中插播一片 10 年前的 Core i7 2600K。

编译器: GCC 10.2 -march=znver2 for AMD, -march=native for Intel, 都使用了 -Ofast 以及相同的兼容性/优化旗，测试结果经 spec 工具判定完全合法可提交。

第三方库: Jemalloc 5.21

SPEC CPU 2017 1.1 tune: base, 3 loop

我们接纳了 4GHZ 同频的目的是为了便于比力 IPC。

以上是纯 IPC 方面的提升幅度。

对于在运行于默认频率（含自动加速）的测试，代表了各人日常的应用感受。

默认频率（ CPU 频率自我放飞了），关闭超线程：

在整数 rate 1copy 测试中，Ryzen 7 5800X 的默频性能比 Ryzen 7 3800X、Ryzen 7 2700X、Core i9 10900K、Core I7 2600K 快约莫 32%、59%、慢 17% 和 80%。

在浮点 rate 1copy 测试中，Ryzen 7 5800X 的默频性能比 Ryzen 7 3800X、Ryzen 7 2700X、Core i9 10900K、Core I7 2600K 快约莫 20%、41%、15% 和 110%。

在整数 speed 测试中，Ryzen 7 5800X 的默频性能比 Ryzen 7 3800X、Ryzen 7 2700X、Core i9 10900K、Core I7 2600K 快约莫 33%、59%、17% 和 89%。

在浮点 speed 测试中，Ryzen 7 5800X 的默频性能比 Ryzen 7 3800X、Ryzen 7 2700X、Core i9 10900K、Core I7 2600K 快约莫 10%、23%、4% 和 207%。

全文总结

必须大图镇文呀。

透过这次针对 Zen 3 微架构测试，各人可以了解到，Zen 3 在很多细节上的变革：

这些诸多的改变，对于 Zen 3 来说，反映到 SPEC CPU 2017 中，最显著的提升领域是整数性能，单线程下，同频比 Zen 2 约莫提升了 22%，浮点相对较少，是 13%，和 Comet Lake 比整数约莫快 22%，浮点约莫快 20%。由于 Comet Lake 具有 10 个内核，所以在多线程浮点中，两者同频性能相当。

默认频率规格下，Ryzen 7 5800X 的提升幅度更大，单线程下整数和浮点分别比 3800X 快大于 32% 和 21%，时隔 一年，这是非常大的提升了（斜眼 Intel）。

和 10 年前的 CPU旗舰 Core i7 2600K 相比，Ryzen 7 5800X 提升幅度显著，这片 Core i7 2600K 已经陪伴我 10 年了，最近已经觉得它很不敷用了，这次和新产物对比后，有点恍如隔世的感觉。

完成这篇文章后，我有一个强烈的感觉：AMD 已然进入了新的纪元，作为消费者的我们，尤其是我这种 10 年不换一次 CPU 的，好像已经没有任何理由拒绝 Zen 3 了。

固然，如果要鸡蛋里挑骨头的话，我觉得 Zen 3 的 L3 Cache 和核间互联依然有一定改进空间，目前的设计高度倾向于追求密度(RDNA 2 用同样的技术实现了 128MB 片上高速缓存)。至于怎么改? 得看 Zen 4 了。☆ﾐ(o*･ω･)ﾉ

再次鸣谢 AMD、映泰、华硕、阿斯加特对这次测试的鼎力支持，没有他们的支持，这篇文章无法完成，同时也感谢各人百忙抽闲阅读本文，行文匆匆，难免有错漏。

如果文章觉得还可以的话，希望能够收获一个赞^^/