C语言模块化封装函数引发RK4仿真代码性能下降咨询

• 核心损耗并非来自函数调用本身的call/ret指令开销（单次调用仅占数个时钟周期，累计影响极小），而是新增的函数边界阻断了编译器默认的跨过程优化（IPO）：
  第一版代码的积分循环直接写在main函数内，编译器做流分析时可以直接推导得到：调用rk4时传入的dim固定为2、函数指针edosys固定指向duffing、步长h全程不变，因此可以做一系列激进优化：将rk4和duffing直接内联到循环中、把变长数组（VLA）tmp/k1~k4替换为固定长度数组、删除duffing里dim判断的无效分支、展开RK4内部的小循环、把对edosys的间接函数调用转为直接调用甚至内联，最终生成的机器码冗余度极低。
  第二版把循环封装到rk4_solution后，编译器默认单函数编译时会假设该函数可能被任意位置的代码调用，传入任意合法的dim、任意的edosys函数指针、任意的ndiv值，因此无法做上述常量传播、死代码删除、内联类优化，只能生成适配所有可能输入的保守机器码，性能自然下降。
• 变长数组（VLA）的额外开销：rk4中double tmp[dim]这类C99变长数组，当dim是编译期已知常量时，编译器会直接把它当成固定长度数组处理，栈分配开销几乎为0；但当dim是函数形参（运行时值）时，每次进入rk4都需要动态调整栈指针，且无法对数组访问做最优寄存器分配、SIMD向量化优化，进一步拉低性能。
• 间接调用开销：封装后rk4_solution接收edosys函数指针作为形参，编译器如果无法确定该指针的固定指向，就只能生成间接调用指令，相比直接调用不仅有额外的指针寻址开销，也大概率无法内联被调用的方程组函数——而方程组函数是热路径中调用频率最高的代码，这部分损耗在复杂场景下会被放大到非常明显的程度。

• 优先开启全程序编译优化：编译时添加链接时优化（LTO）选项，GCC/Clang使用-O3 -flto编译参数，MSVC使用/O2 /GL参数。开启LTO后编译器会在链接阶段把所有代码合并做统一分析，跨函数的常量传播、内联、间接调用消去优化都会正常生效，绝大多数场景下封装前后的性能会完全一致，不需要修改任何业务代码，是成本最低的方案。
• 强制内联热路径封装函数：如果不想开启全程序LTO，可以给rk4_solution、rk4这类热路径上的小函数加强制内联标记，GCC/Clang添加__attribute__((always_inline))修饰，MSVC添加__forceinline修饰，编译器会直接把函数代码嵌入到调用处，完全消除函数边界，运行效果和把逻辑直接写在main里完全一致，同时保留代码的模块化拆分结构。
• 把编译期固定的参数从运行时形参改为编译期常量：
  • 对于固定维度的仿真场景，不要把dim作为运行时参数传递，可以用宏、static const常量、（若允许用C++编译）模板参数传入固定维度值，既可以消除VLA的动态开销，也能让编译器直接删除方程组函数里的无效dim判断分支。
  • 对于固定的方程组函数，不要把它作为函数指针在热路径传递，可以把RK4实现为绑定对应方程组的static inline函数，或者用宏把方程组逻辑嵌入RK4流程，完全消除间接调用开销。
• 替换RK4内的变长数组：不要在rk4内部用VLA申请临时数组，可以在初始化阶段一次性预分配好对应最大维度的临时工作内存，作为参数传入RK4，或者直接定义固定最大长度（比如#define MAX_DIM 16）的临时数组，让数组长度在编译期确定，方便编译器做栈分配和向量化优化。

内容的提问来源于stack exchange，提问作者Luguecos