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

> 本文档最终章。完成了从 [案例一](/concepts/tools/perf-case-studies/01-mode1-o0-baseline.md)（理想对照组）→ [案例二](/concepts/tools/perf-case-studies/02-mode1-o2-comparison.md)（O2 优化效果）→ [案例三](/concepts/tools/perf-case-studies/03-mode2-o0-u-trap.md)（`:u` 陷阱发现）→ [案例四](/concepts/tools/perf-case-studies/04-mode2-o2-u-trap.md)（O2 `:u` 实测）→ [案例五](/concepts/tools/perf-case-studies/05-mode2-o0-full-view.md)（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 不同):
  ```bash
  sudo perf stat -e cycles:u,cycles:k,instructions:u,instructions:k \
                 -p 12253 -- sleep 3
  ```
- **采样窗口**:3.00 秒(perf 等待时长)

## 6.3 原始输出(贴图复刻)

```bash
[chzhuo@shrdlab31 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 程序上"几乎无效"?**

```plantuml
@startuml
skinparam shadowing false
skinparam rectangle {
  RoundCorner 15
}
rectangle "模式 2 O0" as O0 #FFE0B2
rectangle "模式 2 O2" as O2 #C8E6C9
O0 -> O0 : user 态: 2.61G cycles (21.2%)
O0 -> O0 : kernel 态: 9.67G cycles (78.8%)
O0 -> O0 : 总: 12.28G cycles
O2 -> O2 : user 态: 2.49G cycles (20.6%)
O2 -> O2 : kernel 态: 9.62G cycles (79.4%)
O2 -> O2 : 总: 12.11G cycles
note bottom of O0
  O0 user 态的"无用功":
  - ofstream 构造/析构胶水
  - 间接跳转
  - 未内联函数调用
  - 守卫分支
  共 ~0.12G cycles
  = O2 能省的"全部"
end note
note bottom of O2
  O2 优化后的剩余:
  - user 态: 0.06G cycles 的"系统调用包装"
  - kernel 态: 9.62G cycles 的 VFS 路径
  → O2 完全无法触及 kernel 部分
  → 节省 1.4%
end note
@enduml
```

**原因分析**:

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 程序上的"优化效果"对比

```plantuml
@startuml
skinparam shadowing false
skinparam rectangle {
  RoundCorner 15
}
rectangle "模式 1 O0 → O2" as M1 #FFF3E0
rectangle "模式 2 O0 → O2" as M2 #E1F5FE
M1 -> M1 : user 态 12G → 2.5G
M1 -> M1 : 总加速: 4.7 倍
M1 -> M1 : O2 主要工作:DCE 消除 sum += i
M1 -> M1 : **O2 极其有效**
M2 -> M2 : user 态 2.61G → 2.49G
M2 -> M2 : kernel 态 9.67G → 9.62G
M2 -> M2 : 总加速: 1.014 倍
M2 -> M2 : O2 主要工作:内联 ofstream,消除守卫
M2 -> M2 : **O2 几乎无效**
note bottom of M1
  模式 1 = 纯算术循环
  整个工作都在 user 态
  O2 把整个 sum 循环干掉
  → 4.7 倍加速
end note
note bottom of M2
  模式 2 = syscall 风暴
  78.8% 工作在 kernel
  O2 只优化了 21% 工作中的一小部分
  → 1.4% 加速
end note
@enduml
```

## 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 倍。**