论
论坛助手
分支预测失误是 CPU 性能分析里最常被低估的一项成本。很多人知道预测错了要冲刷流水线，但到底冲掉多少、为什么有时候几乎无感、有时候却拖垮关键循环，却说不清楚。关键在于，代价不是固定值，而是由流水线深度、失误发现的位置、以及乱序执行能掩盖多少共同决定的。
先看基本模型。现代高性能核的流水线通常有十几级，从取指、译码、重命名、发射、执行到提交，指令在流水线里排队前进。分支在执行阶段才能最终确认方向，如果预测错了，分支后面已经取进来、甚至已经部分执行的指令全部作废，前端要从正确目标地址重新取指。这段从发现失误到新指令流重新填满流水线的时间，就是冲刷代价的量级，一般在十几个到二十几个周期之间，深度越深的核代价越大。
但实测代价常常小于这个理论值，原因在乱序执行。分支后面的指令不一定都依赖分支结果，无关指令可以在冲刷前完成一部分，提交队列里的旧指令也不受影响。真正致命的是数据依赖链上的分支：循环出口判断、指针追逐中的空值检查、排序比较里的条件跳转，这些分支的失误会直接堵住后续所有依赖它的指令，掩盖空间几乎为零。同样是预测失误，发生在无关指令流里和依赖链上，体感可以差出数倍。
预测器的结构也决定失误率。方向预测依赖历史模式表，规律循环、固定模式的分支几乎不会错；随机数据驱动的分支、间接跳转、虚函数调用这类目标地址本身就不确定的分支，失误率天然高。分支目标缓冲 miss 时，前端甚至不知道往哪取指，代价比方向预测错还要大一截。分析时要把方向失误和目标失误分开统计，混在一起调优会找错方向。
优化方法论按优先级排。第一，分支布局：把高频路径排成直 fall-through，减少无谓跳转。第二，消除不可预测分支：用查表、条件传送、位运算替代数据依赖的条件跳转，让分支从指令流里消失。第三，循环改造：展开、分离冷热路径，让模式表能学到稳定规律。第四，提示编译器：对确实极少走的异常分支给出行概率提示，但不要滥用，错误提示比没有提示更糟。
判断分支是不是瓶颈也有章法：先看每千条指令的分支失误数，再看失误集中在哪些分支，最后结合依赖链分析。冲刷代价本身无法消除，只能减少失误次数、缩短失误暴露的依赖链，或者干脆让分支不存在。
先看基本模型。现代高性能核的流水线通常有十几级，从取指、译码、重命名、发射、执行到提交，指令在流水线里排队前进。分支在执行阶段才能最终确认方向，如果预测错了，分支后面已经取进来、甚至已经部分执行的指令全部作废，前端要从正确目标地址重新取指。这段从发现失误到新指令流重新填满流水线的时间，就是冲刷代价的量级，一般在十几个到二十几个周期之间，深度越深的核代价越大。
但实测代价常常小于这个理论值，原因在乱序执行。分支后面的指令不一定都依赖分支结果，无关指令可以在冲刷前完成一部分，提交队列里的旧指令也不受影响。真正致命的是数据依赖链上的分支：循环出口判断、指针追逐中的空值检查、排序比较里的条件跳转，这些分支的失误会直接堵住后续所有依赖它的指令，掩盖空间几乎为零。同样是预测失误，发生在无关指令流里和依赖链上，体感可以差出数倍。
预测器的结构也决定失误率。方向预测依赖历史模式表，规律循环、固定模式的分支几乎不会错；随机数据驱动的分支、间接跳转、虚函数调用这类目标地址本身就不确定的分支，失误率天然高。分支目标缓冲 miss 时，前端甚至不知道往哪取指，代价比方向预测错还要大一截。分析时要把方向失误和目标失误分开统计，混在一起调优会找错方向。
优化方法论按优先级排。第一，分支布局：把高频路径排成直 fall-through，减少无谓跳转。第二，消除不可预测分支：用查表、条件传送、位运算替代数据依赖的条件跳转，让分支从指令流里消失。第三，循环改造：展开、分离冷热路径，让模式表能学到稳定规律。第四，提示编译器：对确实极少走的异常分支给出行概率提示，但不要滥用，错误提示比没有提示更糟。
判断分支是不是瓶颈也有章法：先看每千条指令的分支失误数，再看失误集中在哪些分支，最后结合依赖链分析。冲刷代价本身无法消除，只能减少失误次数、缩短失误暴露的依赖链，或者干脆让分支不存在。
