解决了一个好多年前的疑惑

AMD Zen 2的软件优化手册上把dispatch对象称为micro-ops (uop)，而Zen 3手册上则是称之为macro-ops (mop)。以前我一直以为这两个架构在这方面没有太大的差异，单纯是文档由不同团队制作导致（AMD的文档质量懂的都懂），但最近经过实际测试发现两个文档的描述都是正确的。

从架构简介上看，Zen 2/3都是6-wide架构，但Zen 2是发射6个uops到后端，Zen 3则是发射6个mops。虽然都是叫6-wide但是背后的含金量完全不同，mop与x86指令基本一一对应（特殊情况下有一对多的fastpath double/ucode和2对1的fused mop），uop则是跟处理器后端具体执行单元的功能一一对应。

那么我们写一个简单的测试来探一探这个区别：测试5条指令的IPC，其中4条采用add指令；由于两个架构都只有4个scalar ALU，这样程序的IPC被限死在5。然后我们在不超过4*add+2*LD+1*ST的前提下，通过调节mem operand占比和剩下的一条指令来生成不同uop数量的程序，观察处理器单周期uop的吞吐。最终观察到Zen 3/4处理器可以单周期发射7个uop（甚至更多，特殊的指令组合可以让x86 ipc达到8），而Zen 2则是被严格限定在了6个uop，超过6个uop之后观察到明显的吞吐下降。

所以其实Zen 2的后端是一个更接近RISC的处理器，指令在流水线非常早期就被拆解成具体执行单元运行的uop进入dispatch/scheduler。Zen 3/4则是完全另一种思路下的产物（更接近Intel？），就连scheduler里存的都还是经过rename后的比x86更CISC的mop指令，scheduler向执行单元发送指令时才会变成具体的uop。如果说Zen 3是6-wide处理器，那么Zen 2实际上更接近4到5-wide；如果说Zen 2是6-wide处理器，那么Zen 3/4则是接近7到8-wide。

再来一个小彩蛋，由于fused macro ops的存在，x86处理器的x86指令IPC可以超过实际rename的宽度。例如下面这一组指令在Zen 3/4上运行可以跑出接近8的IPC，虽然x86 ISA有memory operand的情况下还这么load纯属凑数，并没有什么意义。。

再谈大家耳熟能详的Geekbench，以GB5为例：

GB5的整数子项普遍对ILP极其友好且内存压力偏小。与之前分析的SPEC17区别在于，它太过于顺从超标量流水线处理器设计，缺乏类似mcf/omnetpp/leela这种魔鬼测试。

我想这也是为什么主打低频/宽架构/高IPC的ARM阵营喜欢用它，以及高频IPC几乎没有损失的原因。

GB6我没买license就懒得做分析了（除非谁送我一个）

上一条发出去15分钟就被群友送了GB6 pro，惊了……

那么说好的数据，GB6压缩把lzma换成lz4/zstd之后分支预测压力下降，IPC/内存压力上升；Navigation照搬GB5；HTML/PDF换了库，文件比GB5复杂但负载特征近似；Clang热代码变大。

总体上cache/mem压力变大，不过瓶颈的分布依然没有SPEC17那么均衡。