4、编译器优化：GCC优化等级、LTO链接时优化、Profile Guided Optimization

编译器优化，说白了就是让编译器帮你把代码“拧干水分”。

很多做SITL仿真的朋友，写完代码直接 gcc -O0 就跑了。仿真跑得慢，第一反应是“算法不行”、“硬件不够”。其实很多时候，编译器优化开关都没打开。我个人习惯是，在项目初期就用 -O2 起步，等调通了再上更狠的优化。

4.1 GCC优化等级：从-O0到-Ofast

GCC的优化等级，就像汽车的驾驶模式。经济模式、运动模式、赛道模式，各有各的脾气。

优化等级	编译时间	执行速度	调试友好度	典型场景
`-O0`	最快	最慢	★★★★★	开发调试、单步跟踪
`-O1`	较快	中等	★★★★	快速验证、轻度优化
`-O2`	中等	较快	★★★	日常仿真、性能测试
`-O3`	较慢	最快	★★	发布版本、极致性能
`-Ofast`	最慢	极限	★	数值计算、非标准兼容

-O0：所有优化都关掉。变量不优化进寄存器，循环不展开，函数调用不内联。调试时最友好，但性能最差。我见过有人把仿真代码用 -O0 跑了一周，换成 -O2 后，时间直接砍半。

-O1：开了一些基础优化。比如分支预测优化、局部公共子表达式消除。编译快，性能提升也明显。适合快速迭代时用。

-O2：这是SITL仿真的“甜点区”。它包含了大部分常见的优化，比如函数内联、循环优化、全局寄存器分配。我个人习惯，仿真代码在开发阶段就用 -O2。调试信息虽然少了一点，但性能提升非常可观。

-O3：在 -O2 基础上，增加了更激进的循环展开、向量化等。编译时间变长，代码体积也可能变大。但仿真性能确实能再上一个台阶。

-Ofast：这是最激进的模式。它包含了 -O3 的所有优化，还打破了IEEE浮点标准。比如它会做“快速数学”优化，忽略NaN和无穷大检查。嗯，这里要注意：如果你的仿真涉及精确的数值计算，比如飞行器动力学模型，用 -Ofast 可能会引入微小误差。我曾经在一个无人机仿真项目里用过，结果姿态解算偶尔会飘，排查了两天才发现是 -Ofast 搞的鬼。

核心建议：

开发调试：-O0 -g
日常仿真：-O2 -g
发布版本：-O3 -DNDEBUG
数值敏感场景：慎用 -Ofast

4.2 LTO链接时优化：跨文件的“全局视野”

普通编译，每个源文件是独立编译的。编译器只能看到当前文件里的函数调用。这就好比一个团队，每个人只知道自己手头的活，不知道隔壁在干嘛。

LTO（Link Time Optimization）打破了这堵墙。它在链接阶段，把所有目标文件（.o）的中间表示（IR）合并到一起，然后做全局优化。

举个例子：

// utils.c
int add(int a, int b) {
    return a + b;
}

// main.c
#include <stdio.h>
int add(int, int);
int main() {
    int result = add(3, 4);
    printf("%d\n", result);
    return 0;
}

普通编译下，add 函数会被保留，生成一个函数调用。但开启LTO后，编译器发现 add 只在 main 里被调用一次，而且参数是常量。它会直接把 add(3, 4) 优化成 7，连函数调用都省了。

怎么用？很简单，编译和链接时都加上 -flto：

gcc -flto -O2 -c utils.c -o utils.o
gcc -flto -O2 -c main.c -o main.o
gcc -flto -O2 utils.o main.o -o simulation

LTO的缺点也很明显：链接时间变长。尤其是大型SITL项目，链接时间可能从几秒变成几十秒。但换来的是运行时性能提升，我个人觉得非常值。

小技巧： 如果项目很大，可以试试 -flto=auto 或 -flto=jobserver，让LTO并行执行，能显著缩短链接时间。

4.3 Profile Guided Optimization：让数据说话

PGO（Profile Guided Optimization）是一种“先跑后优化”的技术。它分三步走：

插桩编译：用 -fprofile-generate 编译代码。编译器会在代码里插入一些“探针”，用来记录运行时信息。
运行训练集：用典型的仿真场景运行程序。程序会生成一个 .gcda 文件，里面记录了每个分支的执行次数、循环迭代次数等。
反馈优化：用 -fprofile-use 重新编译。编译器根据上一步的数据，做出更精准的优化决策。

为什么PGO有效？因为编译器在 -O3 下做的很多优化，其实是“猜”的。比如内联哪个函数、展开哪个循环，都是基于静态分析。而PGO给了编译器真实的数据，让它知道哪些代码是热点，哪些是冷路径。

具体操作：

# 第一步：插桩编译
gcc -O2 -fprofile-generate main.c -o simulation_pgo

# 第二步：运行训练集
./simulation_pgo --input typical_scenario.sdf

# 第三步：反馈优化
gcc -O2 -fprofile-use main.c -o simulation_final

我曾经在一个多旋翼SITL项目里用过PGO。仿真场景是城市环境避障，有大量路径规划计算。第一次跑，帧率只有30 FPS。做完PGO后，帧率直接飙到48 FPS。提升超过50%。

避坑指南：

训练集要覆盖典型场景。如果训练集和实际运行场景差异太大，PGO可能反而会降低性能。
PGO编译后的二进制文件，对输入数据敏感。换一个完全不同的仿真场景，效果可能打折扣。
每次修改代码后，需要重新做PGO。否则profile数据会失效。

4.4 三种优化手段的协同使用

这三种优化不是互斥的，而是可以叠加的。我一般这样组合：

开发阶段：-O2 -g，不开LTO和PGO，保证编译速度和调试体验。
性能调优阶段：-O3 -flto，先看LTO能带来多少提升。
发布阶段：-O3 -flto -fprofile-use，把PGO也加上，榨干最后一点性能。

下面这张图，展示了三种优化在编译流程中的位置和作用范围：

从图中可以看到：

编译阶段：-O0 到 -Ofast 作用于单个源文件。这是最基础的优化。
链接阶段：LTO 跨越了文件边界，做全局优化。
运行阶段：PGO 通过实际运行数据，指导编译器做更精准的优化。

这三种优化层层递进，每加一层，性能就往上走一截。但代价是编译时间变长、调试难度增加。你需要根据项目阶段，找到那个平衡点。

一句话总结：

先用 -O2 保底，再用 -flto 打通文件壁垒，最后用 PGO 让数据说话。这三板斧下去，SITL仿真的流畅度会有质的飞跃。

📚 课程目录

4、编译器优化：GCC优化等级、LTO链接时优化、Profile Guided Optimization

4.1 GCC优化等级：从-O0到-Ofast

4.2 LTO链接时优化：跨文件的“全局视野”

4.3 Profile Guided Optimization：让数据说话

4.4 三种优化手段的协同使用