Profile-Guided Optimization（PGO） on Dorkytiger 的小屋

PGO 的原理

Mon, 01 Jan 0001 00:00:00 +0000

一、PGO 解决什么问题

编译器默认的优化是基于通用假设——它不知道你的程序实际运行时哪些分支是热的、哪些是冷的。

// 编译器不知道这两条分支的实际运行频率：
void process(bool is_error) {
    if (is_error) {
        // 编译器假设这两条分支概率是 50/50
        // 但实际上这条分支只占 0.01%
        log_error();
        return;
    }
    // 99.99% 的执行走这里
    do_normal_work();
}

PGO 的做法：

先编译一个带桩（profile-generate）的版本。
用真实负载跑一遍，收集实际的执行行为。
用收集的数据重新编译（profile-use），编译器知道"那条错误分支 99.99% 不执行"→ 把它放到 .text.unlikely 段 + 不再内联 + 不再预取。

二、三步流程

# 第一步：插桩编译
g++ -O2 -fprofile-generate -o my_program main.cpp
# 生成一个插桩后的可执行文件

# 第二步：跑真实负载
./my_program < test_input.txt
# 运行结束后生成 *.gcda 文件（profile 数据）
# 位置：当前目录的 ./ 或环境变量 GCOV_PREFIX 指定

# 第三步：利用 profile 优化编译
g++ -O2 -fprofile-use -o my_program_opt main.cpp
# 编译器读取 *.gcda 中的信息做针对性优化

三、PGO 的实际效果

没有 PGO：
  main → process (50%) → normal (生成两份差不多的代码)
              (50%) → error

有 PGO（profile 显示只走了 0.01% error 路径）：
  编译器做的优化：
    1. normal 路径内联到 process 中（减少一次函数调用）
    2. error 路径移到 .text.unlikely（热代码更紧凑，I-Cache 命中率更高）
    3. normal 路径的基本块排在一起（减少分支跳转）
    4. 寄存器分配策略偏向 normal 路径

实测结果：
    性能提升通常在 10-30%，取决于分支的可预测性。
    浏览器（Chrome）用 PGO 编译后，启动速度提升约 15%。

在你的 ScoreMaster 上应用 PGO

Mon, 01 Jan 0001 00:00:00 +0000

# 假设你的 ScoreMaster 在 RK3588 上编译

# 第一步：插桩编译
aarch64-linux-gnu-g++ -O2 -fprofile-generate -o scoremaster_test \
    src/main.cpp src/core/*.cpp src/logic/*.cpp \
    -I./3rdparty/rknn/include \
    -L./3rdparty/rknn/lib -lrknnrt

# 第二步：在开发板上用测试视频跑一次
./scoremaster_test --test-video test.h264

# 第三步：优化编译
aarch64-linux-gnu-g++ -O2 -fprofile-use -o scoremaster_opt \
    src/main.cpp src/core/*.cpp src/logic/*.cpp

# 对比优化前后：
# perf stat ./scoremaster_test     → 原始性能
# perf stat ./scoremaster_opt      → PGO 后性能
# 你可能看到 IPC 提升、cache-misses 下降

PGO 的注意事项

Mon, 01 Jan 0001 00:00:00 +0000

PGO 最常见的问题：训练数据不具代表性。

❌ 错误的训练负载：
  ./scoremaster --test-video single_static_frame.h264
  → 只有 1 帧画面，profile 显示"detect 分支 100% 走缓存路径"
  → 优化后实际跑视频时 detect 分支频繁缓存未命中，变慢了

✅ 正确的训练负载：
  ./scoremaster --test-video typical_match.h264
  → 包含各种比赛场景的长时间视频
  → 覆盖了"有球/没球/密集/稀疏"等各种路径
  → PGO 优化的代码对真实场景最友好

其他注意：
  - 每次代码更新后需要重新收集 profile（旧的 .gcda 不能用）
  - 多线程程序：profile 数据不会包含线程调度的时序信息
  - PGO 不是魔法：算法复杂度上的优化（O(N^2) → O(N)）比 PGO 的 10-30% 提升大得多

第七阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

PGO 三步骤：
    -fprofile-generate → 跑真实负载 → -fprofile-use

优化效果：
    10-30% 性能提升（主要来自热/冷代码分离 + 分支优化）

关键：
    训练负载必须代表真实使用场景
    测试数据和训练数据不能是同一份（会过拟合）