赶在Zen5/ARL发布之前简单测试最后一代6-wide x86大核性能特性
有趣的是虽然两家在Zen3-4/GLC-RWC这几代IPC接近，性能瓶颈却大相径庭。粗略观察，Intel分支预测失效代价巨大；AMD处理大code footprint的能力不太行而且后端mem bound严重（哪怕是缓存内）
两家PMC有细微区别，数值对比只能算是图一乐
有趣的是虽然两家在Zen3-4/GLC-RWC这几代IPC接近，性能瓶颈却大相径庭。粗略观察，Intel分支预测失效代价巨大；AMD处理大code footprint的能力不太行而且后端mem bound严重（哪怕是缓存内）
两家PMC有细微区别，数值对比只能算是图一乐
👍16
https://www.tomshardware.com/pc-components/cpus/nvidia-blames-intel-for-gpu-vram-errors-tells-geforce-gamers-experiencing-13th-or-14th-gen-cpu-instability-to-contact-intel-support
从当年只要不是脸黑就能人均-0.1V offset随便用，到今天旗舰CPU+旗舰主板默频出厂都能不稳定还得让GPU厂商帮忙背锅处理客诉。Intel也是越来越落魄了。
从当年只要不是脸黑就能人均-0.1V offset随便用，到今天旗舰CPU+旗舰主板默频出厂都能不稳定还得让GPU厂商帮忙背锅处理客诉。Intel也是越来越落魄了。
Tom's Hardware
Nvidia blames Intel for GPU VRAM errors, tells GeForce gamers experiencing 13th or 14th Gen CPU instability to contact Intel support
Even Nvidia is aware of Intel's instability issues with Raptor Lake
😁9
解决了一个好多年前的疑惑
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。
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。
👍20
再来一个小彩蛋，由于fused macro ops的存在，x86处理器的x86指令IPC可以超过实际rename的宽度。例如下面这一组指令在Zen 3/4上运行可以跑出接近8的IPC，虽然x86 ISA有memory operand的情况下还这么load纯属凑数，并没有什么意义。。
👍12
经过我的不断努力，美国在我的知乎推荐时间线上的解体次数已经从每日4-5次降低到每日1-2次。可喜可贺，感觉每一个美国人都应该感谢我。当然马斯克的星舰肯定是会持续爆炸的，这个没救。
😁39
感觉有点玩明白知乎这个推荐算法了。。遇到什么反智推送，最好的应对方法并不是点踩/不感兴趣或者屏蔽该内容，而是点进问题去点赞一个反驳这个内容的回答，这样一段时间内都不太会有跟这个话题相关的内容。看起来点赞的权重远高于其它动作🤣
🙃就这么想做内容下沉去跟抖音快手抢市场，成为根正苗红的NYSE上市的爱国生意企业？
🙃就这么想做内容下沉去跟抖音快手抢市场，成为根正苗红的NYSE上市的爱国生意企业？
😁16💯4
回想过去半年，高通一直在循环往复地做一件事：发Oryon/Snapdragon X Elite的PPT，然后弄几个ES闭门跑分给指定媒体发出去，再跟上代x86比功耗曲线显得自己非常的光鲜亮丽。
结果现在OEM机器大量泄露Geekbench的跑分一看，IPC都给菊厂K9010爆了，更别提最新的Cortex-X，哈哈……
结果现在OEM机器大量泄露Geekbench的跑分一看，IPC都给菊厂K9010爆了，更别提最新的Cortex-X，哈哈……
😁18
X1跟X3在排除缓存之类差异之后实际ipc差距也就个位数百分比，这点差异还没到刷分的境界（可以参考我之前测的都是8M L3的SD8cx gen3的X1和SD8 gen2的X3）
https://www.zhihu.com/pin/1767155181534502912
https://www.zhihu.com/pin/1767155181534502912
Sen0Kaibutsu: 基本上实锤TSV130刷分了 | TSV130在Geekbench6里的IPC表现逼近Cortex-X3
但是在spec_06在内的详细测试中仅相当于Cortex-X1
Geekbench6定向优化实锤了
难不成真是学A13，CPU加AMX？
但你这AMX加上去别不是只是为了刷分啊
再谈大家耳熟能详的Geekbench，以GB5为例：
GB5的整数子项普遍对ILP极其友好且内存压力偏小。与之前分析的SPEC17区别在于，它太过于顺从超标量流水线处理器设计，缺乏类似mcf/omnetpp/leela这种魔鬼测试。
我想这也是为什么主打低频/宽架构/高IPC的ARM阵营喜欢用它，以及高频IPC几乎没有损失的原因。
GB6我没买license就懒得做分析了（除非谁送我一个）
GB5的整数子项普遍对ILP极其友好且内存压力偏小。与之前分析的SPEC17区别在于，它太过于顺从超标量流水线处理器设计，缺乏类似mcf/omnetpp/leela这种魔鬼测试。
我想这也是为什么主打低频/宽架构/高IPC的ARM阵营喜欢用它，以及高频IPC几乎没有损失的原因。
GB6我没买license就懒得做分析了（除非谁送我一个）
❤10