谷歌工程师实测：1个if语句写错，CPU多花20个周期

你的代码里有多少个if判断？100个？1000个？每个猜错的分支都在让CPU白干活。现代处理器会提前预测程序走向，猜错了就要清空流水线重新来——一次失误15到20个周期，高频循环里这就是性能黑洞。

C++20给了程序员一个「作弊器」：直接告诉编译器哪条路更常走。这篇把从标准语法到Linux内核宏的所有手段捋一遍，看完你能立刻动手优化自己的热路径。

C++20的[[likely]]：终于不用写丑宏了

新标准把分支提示做成了原生属性，语法干净到不像C++。

写法直给：把[[likely]]或[[unlikely]]贴在分支语句后面。编译器会重新排布机器码，让高频路径成为"自然下落"——不用跳转，指令缓存更友好。

看个实际场景。网络包处理里，数据包占99%，错误包偶尔冒头：

if (error_code != 0) [[unlikely]] {handle_error();  // 冷路径扔远点}

switch语句也能用：

switch (packet_type) {[[likely]] case PacketType::Data:   // 热路径紧贴前面process_data();break;[[unlikely]] case PacketType::Error:log_and_drop();break;}

注意这是提示不是命令。编译器在-O0可能完全无视，release模式下才会认真考虑你的建议。

__builtin_expect：老派但稳如狗

GCC和Clang用了二十年的内置函数，至今仍是Linux内核的选择。

语法反直觉：第二个参数是"你期望的结果"。0表示"这条件大概率假"，1表示"大概率真"。

// 期望error_code == 0（即条件为假）if (__builtin_expect(error_code != 0, 0)) {// 冷路径// 期望is_valid为真if (__builtin_expect(is_valid, 1)) {// 热路径}

代码看着像咒语。所以工程实践里没人裸写，全包成宏。

LIKELY/UNLIKELY宏：工程界的土办法智慧

这是高性能代码库的通用方言，从内核到游戏引擎都在用。

典型定义长这样：

#if defined(__GNUC__) || defined(__clang__)#define LIKELY(x)   __builtin_expect(!!(x), 1)#define UNLIKELY(x) __builtin_expect(!!(x), 0)#else#define LIKELY(x)   (x)#define UNLIKELY(x) (x)#endif

双感叹号!!是把表达式强转成布尔值，防止宏展开出意外。微软的MSVC没有等价内置函数，所以 fallback 就是原样返回——至少代码能编译。

用起来舒服多了：

if (UNLIKELY(ptr == nullptr)) {return error;if (LIKELY(count > 0)) {process_batch();}

谷歌的Abseil库、Facebook的Folly、Chrome源码里搜一下，这种宏出现频率高得离谱。不是他们不想用C++20，是得照顾老编译器和各种嵌入式工具链。

编译器标志：让工具自己猜

手动标注是精准打击，编译器自动分析则是地毯式轰炸。

GCC和Clang有-fprofile-generate配合-fprofile-use的流程：先跑一遍真实负载采集分支频率，编译第二遍时用数据指导优化。这叫PGO（Profile-Guided Optimization，配置文件引导优化），效果通常比手写提示更准——毕竟实测数据比程序员的直觉靠谱。

LLVM还有个隐藏武器-mbranch-cost，可以调整编译器对分支代价的预估。默认值是1，设成更高会让编译器更激进地展开循环、向量化代码。

但PGO有门槛：需要可复现的测试负载，CI流程得改，增量编译也会变复杂。很多团队卡在"第一遍数据采集"这一步。

什么情况下别用这些技巧

分支提示不是免费午餐，用错地方反而帮倒忙。

第一，别在分支频率五五开的代码上瞎标。编译器会按你的提示排布指令，猜错了代价更高。第二，现代CPU的分支预测器已经很聪明，对简单模式（循环计数器、交替真假）的识别准确率能到95%以上，人工干预是画蛇添足。

第三，也是最容易踩的坑：[[likely]]只影响代码布局，不改变语义。有人误以为标了[[unlikely]]的异常分支就不会执行——该崩溃照样崩溃，该抛异常照样抛。

第四，虚函数调用、函数指针、std::function这种间接跳转，分支提示完全无效。CPU连目标地址都不知道，更别提预测走哪条路了。

那什么时候该出手？热路径明确且稳定，比如错误处理、边界检查、日志级别判断；或者PGO没法用的场景，比如内核代码、实时系统、启动时就得最优化的路径。

一个数字：谷歌搜索团队的真实案例

2019年Chromium的一次提交记录很有意思：工程师在DNS预解析的回调里加了LIKELY宏，标注"缓存命中"为热路径。单这一个改动，该模块的CPU占用下降了3.2%。

3.2%听着不多，但乘以谷歌的搜索量，省下的机器资源够养一个小团队。

你的代码库里，有多少个if的判断概率从来没被量过？