C++执行速度测试：usleep为何影响临界区外的时间测量结果

你测量到的usleep(2000)对耗时结果的影响，并非是usleep本身的执行时间被计入了gettimeofday包裹的计时区间，而是它改变了下一轮测量启动前的系统与CPU运行状态，这些状态带来的额外开销会被直接计入下一轮的计时结果，核心影响因素如下：

• 缓存与分支预测的冷热状态差异
  2ms的休眠周期足够CPU将上一轮执行用到的gettimeofday、test函数指令从L1/L2高速缓存中淘汰，同时清空对应的分支预测记录、失效相关的缓存行。下一轮计时启动后，CPU需要重新从内存加载指令、重建分支预测状态，这部分冷启动开销全部会落在start到stop的计时区间内。如果移除usleep，循环紧密执行时相关指令和状态会一直留在缓存中处于热状态，测得的耗时会明显更低。
• CPU调频机制的干扰
  调用usleep会让当前线程主动阻塞让出CPU，内核的CPU调频模块检测到核心空闲后，会快速将核心频率降至低功耗档位。当休眠结束线程恢复执行时，CPU从低频切回最高性能频率需要数毫秒的响应时间，也就是说下一轮测量的代码是运行在非最高性能的频率下，执行速度本身更慢，测得的耗时自然更高。没有usleep时线程持续占用CPU，核心会一直维持在最高性能频率，代码执行速度更快。
• 上下文切换与TLB失效的残留开销
  usleep作为系统调用会触发用户态与内核态的切换，休眠期间内核大概率会将当前线程调度出CPU核心，转而运行其他进程。当线程休眠结束重新被调度回核心时，会伴随上下文恢复、TLB（地址翻译高速缓存）失效的额外开销，这些残留影响会导致下一轮计时区间内的指令执行、gettimeofday系统调用出现额外的地址翻译、缓存未命中开销，最终拉高测量值。

额外需要注意：你实现的test函数仅包含一个无实际逻辑的空循环，开启编译优化（如-O2）时编译器会直接删除整个循环，test函数实际只有函数调用和返回的纳秒级开销，这种情况下系统状态扰动带来的波动占比极高，会把usleep的影响放大得非常明显。

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