C语言函数微基准测试：方法合理性与优化级别选择疑问

测试方法的问题与改进 #

你当前的测试代码存在计时开销占比过高的问题，每次循环都调用两次clock()，这个操作本身的耗时会干扰真实的函数执行时间，尤其是在函数执行较快时误差更大。建议优化测试代码，先进行热身循环让CPU缓存加载完毕，再一次性计时整个迭代循环：

// 热身循环，避免缓存冷启动影响
#define WARMUP_ITER 1000
for (int i = 0; i < WARMUP_ITER; ++i) {
    doFun(input, output);
}

// 正式计时，减少单次计时的开销
clock_t startTime = clock();
for (int i = 0; i < ITERATIONS; ++i) {
    doFun(input, output);
}
clock_t endTime = clock();
double totalTime = (double)(endTime - startTime) / CLOCKS_PER_SEC;
printf("Time: %f\n", totalTime);

优化级别选择：优先用-O2 #

必须选择-O2（或-O3）进行有意义的算法对比，原因如下：

• -O0是关闭所有优化的调试模式，编译器会严格按照源码生成冗余代码（比如变量频繁读写内存而非寄存器、不做循环展开、不消除无用操作），此时的性能完全不能反映算法本身的效率，只能体现未优化机器码的执行成本。
• -O1仅开启基础优化，部分关键优化（如深度循环展开、SIMD指令调度）未完全启用，无法充分展现算法的性能差异。
• -O2是生产环境标准优化级别，会启用绝大多数安全的优化（寄存器分配、常量传播、循环展开、分支预测优化等），能真实反映算法和实现的性能优势，尤其是SSE这类SIMD优化，在-O2下能最大化发挥并行性。

-O0下结果异常的原因 #

1. 计时开销占比过高：-O0下函数本身执行速度慢，但每次clock()调用的固定开销在总耗时中的占比被放大，掩盖了函数真实的性能差异，甚至导致结果反转。
2. 未优化代码放大额外开销：
   • Quick函数可能包含更多分支或变量操作，在-O0下这些操作都会生成低效的机器码（比如变量每次读写都访问内存），原本的算法优势被冗余操作抵消，导致比Native函数更慢。
   • SSE函数的并行优势依赖高效的内存访问和指令调度，但-O0下编译器不会优化内存操作，也不会自动循环展开来适配SSE的并行特性，导致无法达到理论上的4倍性能提升。
3. SIMD优化未生效：即使你手动编写了SSE intrinsics，-O0下编译器也不会做配套优化（比如指令重排消除延迟），使得SSE指令的效率大打折扣。

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