为何__faststorefence比_ReadWriteBarrier的计时结果更稳定？

核心原因在于这两个屏障的层级完全不同，结合__rdtsc的特性就能解释清楚：

• _ReadWriteBarrier 只是编译器层面的屏障：它只告诉编译器“别重排我前后的读写指令”，但不会生成任何CPU硬件指令。也就是说，CPU该怎么乱序执行还是怎么来——比如__rdtsc执行时，之前的存储操作可能还在CPU的写缓冲区里没刷出去，或者之后的内存操作提前跑了，这就导致每次读取时间戳的时机都不确定，计时结果自然波动大。

• __faststorefence 是CPU硬件级的存储屏障：它会生成sfence指令，强制CPU把屏障之前所有未完成的存储操作都刷到内存，确保这些操作全局可见后，才允许执行屏障后面的指令。再配合你代码里的_mm_lfence（加载屏障），等于给__rdtsc的前后都加上了严格的“内存操作完成”约束：

  1. 执行__rdtsc前，所有之前的加载、存储操作都已经收尾，CPU处于内存操作“干净”的状态；
  2. 执行__rdtsc后，后续的内存操作也不能提前跑到__rdtsc之前执行，不会干扰时间戳的读取。

回到你的计时函数场景：__rdtsc读的是CPU的时间戳计数器，它的稳定性完全取决于执行时CPU的状态。如果每次读时间戳时，CPU都有数量不确定的未完成内存操作，那计时差值就会包含这些操作的延迟，结果就会忽大忽小。而__faststorefence把这些不确定的内存操作都“拍平”了，让每次__rdtsc都在一致的CPU状态下执行，所以计时结果更稳定。

顺便提一句：你现在的_mm_lfence+__faststorefence组合，其实是在模拟rdtscp指令的部分效果（rdtscp自带隐式存储屏障），但这种写法比直接用rdtscp更灵活，也能严格控制__rdtsc的执行顺序。

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