C++23程序v3与v4的duration_2差异：为何受后置F_CONSTNESS影响？

测试背景 #

• 测试环境：使用Visual Studio 2022 v17.10.4编译生成x86-64优化版本，运行于AMD Ryzen 5 PRO 5650U CPU
• 测试对象：一段C++23程序，通过组合DEST_STORAGE、NEWLINE_CHAR、F_CONSTNESS三个宏定义生成8个不同版本
• 测试结果：
  • 多数版本中duration_2的运行时长约为duration_1的0.5倍，但v1、v2、v4为特例
  • v3与v4仅F_CONSTNESS宏取值不同：
    • v3：F_CONSTNESS设为const，main函数中的if分支被编译器优化移除
    • v4：F_CONSTNESS设为空，if分支代码被保留但实际不会执行

核心问题 #

为何duration_2的运行时长会受位于测量代码之后的F_CONSTNESS宏影响？

解答 #

这本质是编译器全局优化联动与CPU微架构特性共同作用的结果，具体可拆解为两点：

1. 编译器全局优化改变代码布局
   现代编译器（如MSVC 2022的优化器）会进行全局数据流分析与代码生成规划。当F_CONSTNESS为const时，编译器能明确判定if分支永远不会执行，直接将这段代码从最终二进制中移除；而当F_CONSTNESS为空时，即便分支逻辑上不会触发，编译器无法彻底确认（或未触发完全删除的优化规则），会保留这段冗余代码。

这段冗余代码的存在与否，会改变整个程序二进制的代码段内存布局——测量代码（对应duration_1和duration_2的执行逻辑）在内存中的位置、与其他代码的相对偏移都会发生变化，进而影响CPU指令缓存（L1I）的命中率、分支预测器状态，甚至流水线的指令预取效率。

2. CPU微架构对代码布局敏感
   AMD Ryzen 5 PRO 5650U基于Zen 3架构，该架构对代码布局的细节非常敏感：

• 若v4中保留的冗余if分支刚好占据了测量代码附近的缓存行，会导致测量代码的指令缓存命中率下降，直接拉长执行时间；
• 即便冗余代码不会被执行，分支预测器仍可能提前加载这段分支的指令，干扰流水线的预取节奏，间接影响前置测量代码的执行效率。

简言之：后续代码并未直接修改测量逻辑，但其存在与否改变了整个程序的二进制结构，触发了CPU微架构层面的性能波动，最终体现在duration_2的运行时长差异上。

内容的提问来源于stack exchange，提问作者Dr. Gut