为何结构体封装float的乘法在O3优化下比float直接乘法更快？

我封装了一个仅含float成员的Mono结构体，用于支持单float或RGB三float初始化的标量值需求，并重载了乘法运算符。为测试该封装对性能的影响，我编写了基准测试：分别执行1亿次Mono与float的乘法、float与float的乘法，得到以下结果：

• 无优化编译（g++ test.cpp）：Mono*float耗时841122微秒，float*float耗时656197微秒，结构体乘法更慢
• 开启O3优化编译（g++ test.cpp -O3）：Mono*float耗时75494微秒，float*float耗时86176微秒，结构体乘法反而更快

我认为这是优化异常导致的，想了解测试结果背后的原因。

这不是优化异常，而是GCC在O3级别下多种优化策略共同作用的结果，具体原因如下：

• 函数调用开销的消除
  无优化编译时，Mono的乘法运算符以普通函数调用形式执行，存在栈帧创建、参数传递、返回值处理等额外开销，自然比原生float直接乘法慢。而O3优化强制开启函数内联（-finline-functions），编译器会将Mono乘法运算符的代码直接嵌入调用处，完全消除函数调用的额外开销，此时结构体乘法的核心逻辑和原生float乘法一致。

• 寄存器分配与指令调度的差异
  O3优化下，编译器会进行更智能的寄存器分配和指令流水线调度。对于单纯的float乘法循环，编译器生成的指令序列更容易出现寄存器冲突或流水线停顿；而Mono结构体作为自定义类型，编译器在分析代码时可能会更高效地规划寄存器使用，或者将结构体成员的运算与其他指令更好地并行调度，从而提升执行效率。

• 自动向量化与循环展开的效果差异
  O3级别默认开启自动向量化（-ftree-vectorize）和循环展开（-funroll-loops）。Mono结构体的乘法操作，编译器更容易将其识别为独立的、可批量处理的运算单元，从而生成SIMD指令（如SSE、AVX）一次性完成多个乘法操作；而原生float的乘法循环，可能因变量的使用方式或循环结构，编译器的向量化优化效果不如结构体版本理想，导致执行速度稍慢。

• 编译器优化策略的偏好
  部分场景下，编译器对自定义类型的运算会采用更激进的优化策略，而原生基础类型的运算可能因逻辑过于简单，编译器的优化力度反而有所保留。Mono结构体的包装让编译器将其视为一个独立的运算单元，进而应用了更高效的优化组合。

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