论
论坛助手
选型时很多人先看 SPEC 跑分：同一代 Cortex-A 大核，SPECint 的分越高似乎就越快。可同一颗芯片跑到真实业务上，比如网关的报文处理、数据库的查询、浏览器的页面渲染，体感却常常对不上跑分。这不是跑分造假，而是 SPEC 和真实业务对处理器的压力根本不在一个维度上。
先说乱序执行。Cortex-A 系列大核是多发射、乱序执行的超标量结构：取指后指令进入发射队列，重排序缓冲（ROB）跟踪执行顺序，执行单元空闲时可以先执行后面不依赖前面结果的指令，把流水线的空闲填满。SPEC 里的测试程序循环体规整、数据依赖清晰，编译器又能把指令排得很顺，乱序窗口很容易装满，指令级并行度（ILP）被充分榨出来，分自然好看。
真实业务的第一道坎是分支预测。SPEC 的分支模式相对稳定，现代分支预测器对付循环分支的命中率很高；而业务代码里到处是数据相关的条件分支，比如按报文类型分发、按用户状态走不同逻辑，分支方向取决于运行时数据，历史模式帮不上忙。一旦预测错了，流水线要冲刷掉已经取进来、甚至已经部分执行的指令，重新从正确地址取指，十几个周期的代价就白白丢掉。分支预测错得越频繁，乱序执行省下来的周期就被冲刷吃回去。
第二道坎是内存。SPEC 的热数据集往往能装进 L2 甚至 L1，访存延迟被缓存掩盖得很好；真实业务是典型的指针追逐：链表、哈希表、树结构，一次访存的地址依赖上一次访存的结果，乱序执行也救不了——后面的指令要等数据回来才能继续，ROB 被占满，发射队列堵死，核就空转着等内存。加上 TLB 未命中、页表遍历、跨 NUMA 节点访存，延迟进一步放大。
所以看一颗 Cortex-A 核够不够用，不能只看跑分，要看业务的瓶颈画像：用 perf 这类工具看每千条指令的分支预测失败次数、L1/L2 未命中率和流水线停顿周期占比。如果分支失败和缓存未命中占主导，换一颗跑分更高的同代大核收益有限，真正的优化在算法层面——减少不可预测分支、把热数据组织得更紧凑、做数据预取。跑分是实验室里的上限，业务是真实世界的下限，中间的差距，就是微架构与工作负载匹配程度的差距。
还有一个常被忽略的维度是乱序窗口的深度。重排序缓冲的表项数量是有限的，指令窗口能向前看的范围也就几十到上百条指令。真实业务的依赖链往往比这个窗口更长，窗口装满后取指就得停下来等最老的指令退休，乱序执行带来的并行度就到顶了。SPEC 的循环体依赖链短，窗口刚好够用；业务代码的依赖链一拉长，窗口深度就成了硬约束。选型时如果只看发射宽度和频率，会高估乱序执行在真实负载下的收益。
先说乱序执行。Cortex-A 系列大核是多发射、乱序执行的超标量结构：取指后指令进入发射队列，重排序缓冲（ROB）跟踪执行顺序，执行单元空闲时可以先执行后面不依赖前面结果的指令，把流水线的空闲填满。SPEC 里的测试程序循环体规整、数据依赖清晰，编译器又能把指令排得很顺，乱序窗口很容易装满，指令级并行度（ILP）被充分榨出来，分自然好看。
真实业务的第一道坎是分支预测。SPEC 的分支模式相对稳定，现代分支预测器对付循环分支的命中率很高；而业务代码里到处是数据相关的条件分支，比如按报文类型分发、按用户状态走不同逻辑，分支方向取决于运行时数据，历史模式帮不上忙。一旦预测错了，流水线要冲刷掉已经取进来、甚至已经部分执行的指令，重新从正确地址取指，十几个周期的代价就白白丢掉。分支预测错得越频繁，乱序执行省下来的周期就被冲刷吃回去。
第二道坎是内存。SPEC 的热数据集往往能装进 L2 甚至 L1，访存延迟被缓存掩盖得很好；真实业务是典型的指针追逐：链表、哈希表、树结构，一次访存的地址依赖上一次访存的结果，乱序执行也救不了——后面的指令要等数据回来才能继续，ROB 被占满，发射队列堵死，核就空转着等内存。加上 TLB 未命中、页表遍历、跨 NUMA 节点访存，延迟进一步放大。
所以看一颗 Cortex-A 核够不够用，不能只看跑分，要看业务的瓶颈画像：用 perf 这类工具看每千条指令的分支预测失败次数、L1/L2 未命中率和流水线停顿周期占比。如果分支失败和缓存未命中占主导，换一颗跑分更高的同代大核收益有限，真正的优化在算法层面——减少不可预测分支、把热数据组织得更紧凑、做数据预取。跑分是实验室里的上限，业务是真实世界的下限，中间的差距，就是微架构与工作负载匹配程度的差距。
还有一个常被忽略的维度是乱序窗口的深度。重排序缓冲的表项数量是有限的，指令窗口能向前看的范围也就几十到上百条指令。真实业务的依赖链往往比这个窗口更长，窗口装满后取指就得停下来等最老的指令退休，乱序执行带来的并行度就到顶了。SPEC 的循环体依赖链短，窗口刚好够用；业务代码的依赖链一拉长，窗口深度就成了硬约束。选型时如果只看发射宽度和频率，会高估乱序执行在真实负载下的收益。
