分支预测失败会导致流水线清空重填，代价10–20周期，表现为branch-misses>5%且cpi升高；应通过__builtin_expect、卫语句、查表/位运算等减少不可预测分支，并验证汇编布局与性能数据。
分支预测失败会导致什么性能现象？
现代 CPU 在遇到 if、switch、循环跳转等分支时，会提前猜测下一条指令执行路径。一旦猜错（即“分支预测失败”），流水线就得清空重填，典型代价是 10–20 个周期——相当于几十纳秒，在热点循环里就是实打实的吞吐瓶颈。
常见症状包括：perf stat -e cycles,instructions,branch-misses 显示 branch-misses 占分支总数 >5%，且 CPI（cycles per instruction）明显升高；用 perf record -e branch-misses 定位到某段 if 判定密集的循环体内。
怎么让编译器减少不可预测分支？
不是靠手写汇编，而是引导编译器生成更利于预测的代码。关键在两点：消除隐含分支 + 提供预测倾向提示。
- 用
__builtin_expect（GCC/Clang）显式告诉编译器分支走向，比如if (__builtin_expect(ptr != nullptr, 1))告诉它“大概率成立”，编译器会把真分支放直通路径上 - 避免在热路径用
std::vector::at()（带边界检查的分支），改用operator[]（无检查，但需确保索引合法） - 把多层嵌套
if拆成卫语句（guard clause），让高概率失败路径尽早退出，减少深层预测压力 - 对布尔条件，优先写成
if (likely_flag)而非if (!unlikely_flag)—— 否定形式会让编译器更难优化
哪些场景适合用查表或位运算替代分支？
当分支逻辑基于小范围整数输入（如状态码、枚举值、低比特掩码），且分支结果可预计算时，查表或位操作几乎总比分支快，因为完全消除了预测开销。
立即学习“C++免费学习笔记（深入）”；
例如：将 switch (op) { case ADD: ... case MUL: ... } 替换为函数指针数组 static const func_ptr_t dispatch[OP_MAX] = { [ADD] = add_impl, [MUL] = mul_impl };，再用 dispatch[op]() 调用。注意：OP_MAX 必须小（通常 ≤64），且 op 必须已校验越界，否则查表本身会引入新分支。
另一个典型是符号处理：不用 if (x ，改用 <code>x ^ ((x >> (sizeof(x)*8-1)) & (x ^ -x))（仅限补码整数），但务必加注释并测试——可读性代价很大，只在极致热点处用。
为什么 [[likely]] 和 [[unlikely]] 有时没效果？
C++20 的属性只是建议，编译器可以忽略。实际生效取决于：是否启用优化（-O2 或更高）、目标架构是否支持（x86-64 支持良好，某些嵌入式后端不识别）、以及该分支是否被内联进热点函数。最常踩的坑是：
- 属性写在了未内联的函数声明上，而调用点没内联，分支仍在 callee 中，属性失效
- 用在模板实例化中，但编译器因 ODR 或调试信息保留了多个副本，预测提示未传播到最终代码
- 配合
-fno-branch-probabilities这类反向选项，直接禁用所有分支概率分析
验证方法：编译后用 objdump -d 看汇编，确认预测倾向是否反映在代码布局上（高概率路径是否连续、无跳转）。
真正难的是平衡——过度“优化”分支可能让代码体积膨胀、L1i 缓存压力上升，反而降低 IPC。得看 perf 数据说话，不是所有 if 都值得动。
