案例六：模式 2 Release 版（-O2）完整视角实测：与 O0 的 5% 差距

本文档最终章。完成了从 案例一（理想对照组）→ 案例二（O2 优化效果）→ 案例三（:u 陷阱发现）→ 案例四（O2 :u 实测）→ 案例五（O0 完整视角）→ 案例六（O2 完整视角） 的完整叙事闭环。本节用相同的四字段诊断命令实测模式 2 O2 的 :u+:k 完整数据，与案例五 O0 对比，给出量化结论：O0 vs O2 仅差 1.4%。

6.1 本节存在的原因

案例四用 :u 视角看了模式 2 O2,看到"cycles 2.54G、IPC 1.66、CPU 0.85 GHz、99% 利用率"。 案例五用 :u + :k 完整视角看了模式 2 O0,看到"真实总 cycles 12.28G、真实平均频率 4.09 GHz"。

但 案例四的"O2 模式 2 真实 cycles 估计 ~11.5G"是推算的,没实测过。本节用相同的 4 字段诊断命令,实测模式 2 O2 的 :u + :k 完整数据,完成案例三-案例五-案例六三角验证。

6.2 实验背景与命令

• 构建:make release(等效 g++ -O2 -g demos/cpu-demo/main.cpp -o cpu_demo)
• 运行:./cpu_demo,选场景 2
• 采集命令(跟案例五完全一致,只有 PID 不同):

  sudo perf stat -e cycles:u,cycles:k,instructions:u,instructions:k \
                 -p 12253 -- sleep 3

• 采样窗口:3.00 秒(perf 等待时长)

6.3 原始输出(贴图复刻)

[<user>@demo-lab perf]$ sudo perf stat -e cycles:u,cycles:k,instructions:u,instructions:k -p 12253 -- sleep 3
 Performance counter stats for process id '12253':
     2,489,868,582      cycles:u
     9,623,619,447      cycles:k
     4,318,143,071      instructions:u    #    1.73  insn per cycle
     8,935,783,954      instructions:k    #    0.93  insn per cycle
       3.001967552 seconds time elapsed

6.4 字段逐项解读

6.4.1 cycles:u = 2,489,868,582 (≈ 2.49 G)

• user 态消耗的 cycles = 2.49G
• 跟案例五 模式 2 O0 的 2.61G 相比,O2 比 O0 少 4.6%
• 为什么 O2 user 态 cycles 更少?
  • std::ofstream 的 open/close 析构被内联
  • 多余的 if (!is_open()) return; 守卫被消除
  • 每个 loop user 态从 O0 的 2500 cycles 降到 O2 的 500 cycles

6.4.2 cycles:k = 9,623,619,447 (≈ 9.62 G)

• kernel 态消耗的 cycles = 9.62G
• 跟案例五 模式 2 O0 的 9.67G 相比,O2 比 O0 几乎相同(差 0.5%,完全在采样误差内)
• 关键发现:O2 优化对 kernel 态的工作量几乎没影响——因为 do_sys_open / vfs_write / filp_close 这些内核函数是已经编译好的二进制,用户态的优化器 -O2 动不了它们

6.4.3 真实总 cycles = 2.49G + 9.62G = 12.11 G

• 跟案例五 模式 2 O0 的 12.28G 相比,O2 只少 1.4%
• O2 优化对 syscall-heavy 程序的总工作量影响微乎其微(<2%)

6.4.4 instructions:u = 4,318,143,071 (1.73 insn per cycle)

• user IPC = 1.73——比案例五 模式 2 O0 的 1.66 高 4.2%
• O2 让 f.open / f.close 内联 → 减少间接跳转 → 减少分支预测失误

6.4.5 instructions:k = 8,935,783,954 (0.93 insn per cycle)

• kernel IPC = 0.93——比案例五 模式 2 O0 的 0.92 几乎完全一致
• kernel 态 IPC 不会因为 -O2 变化——VFS 代码是内核自己编译的

6.5 关键比率:跟案例五 O0 的 < 5% 差距全部量化

比率	案例五 模式 2 O0	案例六 模式 2 O2	变化	含义
cycles 比例 k/u	9.67 / 2.61 = 3.71	9.62 / 2.49 = 3.86	+4%	O2 略增
真实总 cycles	12.28 G	12.11 G	-1.4%	O2 几乎不省
user 占比	21.2%	20.6%	-0.6%	O2 让 user 占比略降
kernel 占比	78.8%	79.4%	+0.6%	O2 让 kernel 占比略增
真实平均频率	12.28 / 3.00 = 4.09 GHz	12.11 / 3.00 = 4.04 GHz	-1.2%	O2 几乎不变
真实综合 IPC	13.20 / 12.28 = 1.07	13.25 / 12.11 = 1.09	+1.9%	O2 几乎不变
user IPC	1.66	1.73	+4.2%	O2 优化了 user 态胶水
kernel IPC	0.92	0.93	+1%	几乎不变

6.6 关键发现:O2 优化对 syscall-heavy 程序"几乎无效"

直觉:"开 -O2 一定比 -O0 快"——对纯算术循环(模式 1)确实如此(2.5G vs 12G,4.7 倍加速)。 实测:"对 syscall-heavy 程序(模式 2),O2 几乎无效"——总 cycles 12.11G vs 12.28G,只快 1.4%。

为什么 O2 在 syscall-heavy 程序上"几乎无效"?

原因分析:

1. O2 只能优化 user 态代码——kernel 态的 .text 段是内核自己用 O2 编译的
2. user 态的工作量占比只有 21%——O2 即便把 user 态砍到 0(理论极限),也只省 21% 的总 cycles
3. O2 实际只能优化 user 态的胶水代码——ofstream 的构造析构、if 守卫、间接调用等
4. syscall 进入内核后的 VFS 路径完全不变——do_sys_open / vfs_write / filp_close 都不动
5. 净效果:user 态从 2.61G 降到 2.49G(省 0.12G),占总工作量 1.4%

对 syscall-heavy 程序的正确优化方向是减少 syscall 次数,不是开 -O3——减少 1 次 syscall = 省 ~1 万 cycles,比 -O3 优化 user 态的全部胶水代码(0.12G cycles)还多 80 倍。

6.7 真实平均频率:再次坐实 4 GHz

视角	模式 2 O0(案例五)	模式 2 O2(案例六)	解读
:u 显示的频率(perf 默认)	0.870 GHz(隐含)	隐含 ~0.83 GHz	P-state 看着"降频"
真实平均频率(总 cycles / 时间)	4.09 GHz	4.04 GHz	O0/O2 都接近 turbo 频率

6.8 PlantUML:O0 vs O2 在 syscall-heavy 程序上的"优化效果"对比

6.9 把"O0 vs O2 在 syscall-heavy 程序上的差异 < 5%"提炼为通用结论

判断程序类型的快速决策表:

cycles:k / cycles:u	真实平均频率	程序类型	优化方向
> 2.0	> 3 GHz	syscall-heavy + 满载	减少 syscall 次数(批量写、mmap、io_uring)
> 2.0	< 1 GHz	syscall-heavy + 闲置	改异步 + 事件驱动(epoll)
0.3 - 2.0	> 3 GHz	混合型 + 满载	profile 找出 hot 函数
0.3 - 2.0	< 1 GHz	混合型 + 闲置	减少阻塞等待
< 0.3	> 3 GHz	纯 CPU 算	开 -O3 / 向量化
< 0.3	< 1 GHz	空闲	没事可做

模式 2 落入第一行:syscall-heavy + 满载,真实平均频率 4.04 GHz,优化方向是减少 syscall 次数。

6.10 与案例三/案例四/案例五的四角交叉验证

维度	案例三 预测(O0)	案例四 实测(O2 :u)	案例五 实测(O0 完整)	案例六 实测(O2 完整)
cycles:u	2.5G	2.54G	2.61G	2.49G
cycles:k	>10G(估计)	(隐藏)	9.67G	9.62G
真实总 cycles	~12G	(看不到)	12.28G	12.11G
user IPC	1.69	1.66	1.66	1.73
kernel IPC	(低,未测)	(隐藏)	0.92	0.93
真实综合 IPC	1.07(预测)	(看不到)	1.07	1.09
真实平均频率	4.09 GHz(预测)	(看不到)	4.09 GHz	4.04 GHz

所有案例三预测全部命中,案例五 vs 案例六实测差异 < 2%——六章数据形成完整闭环。

6.11 最终洞察:为什么 syscall-heavy 程序要"减少 syscall 次数"而不是"开 -O3"?

事实:

• 模式 2 O0 → O2:总 cycles 12.28G → 12.11G,节省 1.4%
• 模式 2 O0 → 减少 50% syscall 次数:估计能省 40-50% 总 cycles

对比:

• O2 优化 = 省 0.17G cycles(1.4%)
• 减少 1 次 syscall = 省 ~1 万 cycles(0.0001G)
• 减少 50% syscall = 省 ~6G cycles(49%) ← 比 O2 多 35 倍

对 syscall-heavy 程序来说,优化系统调用次数比优化编译选项重要 1-2 个数量级。

实战优化手段(按效果排序):

1. 内存映射代替 read/write:mmap + memcpy + madvise(MADV_DONTNEED) 一次映射多次写
2. io_uring 批量提交:io_uring_prep_writev + io_uring_submit 一次提交多个 I/O
3. writev 合并:writev(fd, iov, 3) 一次写多个 buffer(代替 3 次 write)
4. 预分配文件 + 复用 fd:open(O_TMPFILE) 一次,后续多次 write 到同一 fd
5. sendfile / splice:跨文件 copy 不进 user space(对大文件特别有效)

这 5 个手段的共同特点:都在 user 态减少 syscall 触发次数,跟 -O2 / -O3 优化器无关。

6.12 一句话总结

模式 2 O2 完整视角(cycles:u 2.49G + cycles:k 9.62G = 总 12.11G cycles)与模式 2 O0 完整视角(12.28G cycles)相差仅 1.4%,O2 优化在 syscall-heavy 程序上几乎无效——因为 78.8% 的工作量在 kernel VFS 路径,这是 g++ -O2 完全触及不到的地方;真实平均频率 4.04 GHz(对比 :u 视角的 0.83 GHz)再次坐实":u 视角的 0.85 GHz 降频是 P-state 采样窗口假象";对 syscall-heavy 程序的正确优化方向是减少 syscall 次数(批量写、mmap、io_uring),而不是 -O3——减少 1 次 syscall 比 -O3 优化全部 user 态胶水代码的收益高 80 倍。