基准测试、代码重新排序、易失性

Question

我决定要对一个特定的函数进行基准测试，所以我天真地编写了这样的代码:

#include <ctime>
#include <iostream>

int SlowCalculation(int input) { ... }

int main() {
    std::cout << "Benchmark running..." << std::endl;
    std::clock_t start = std::clock();
    int answer = SlowCalculation(42);
    std::clock_t stop = std::clock();
    double delta = (stop - start) * 1.0 / CLOCKS_PER_SEC;
    std::cout << "Benchmark took " << delta << " seconds, and the answer was "
              << answer << '.' << std::endl;
    return 0;
}

一位同事指出，我应该将start和Stop变量声明为易失性，以避免代码重新排序。例如，他建议优化器可以像这样有效地重新排序代码：

    std::clock_t start = std::clock();
    std::clock_t stop = std::clock();
    int answer = SlowCalculation(42);

起初，我怀疑这种极端的重新排序是允许的，但经过一些研究和实验，我知道是允许的。

但volatile感觉不是正确的解决方案；volatile真的只是用于内存映射I/O吗？

然而，我添加了< code>volatile,发现不仅基准测试花费的时间明显更长，而且每次运行之间也非常不一致。在没有volatile的情况下(幸运的是确保代码没有被重新排序)，基准测试持续花费600-700 ms。在使用volatile的情况下，通常花费1200 ms，有时超过5000 ms。两个版本的反汇编清单除了寄存器的不同选择之外，几乎没有任何区别。这让我想知道是否有另一种方法来避免代码重新排序，而不会产生如此巨大的副作用。

我的问题是：

在这样的基准测试代码中，防止代码重新排序的最好方法是什么？

我的问题类似于这个（这是关于使用 volatile 来避免省略而不是重新排序），这个（它没有回答如何防止重新排序）和这个（争论问题是代码重新排序还是死代码消除）。虽然这三个人都在这个确切的主题上，但没有一个真正回答我的问题。

更新：答案似乎是我的同事错了，像这样的重新排序与标准不一致。我已经投票支持了所有这么说的人，并将赏金授予马克西姆。

我见过一个案例(基于这个问题中的代码)，Visual Studio 2010按照我所展示的方式对时钟调用进行了重新排序(仅在64位版本中)。我试图做一个最小的案例来说明这一点，这样我就可以在Microsoft Connect上提交一个bug。

对于那些认为volatile应该慢得多，因为它会强制对内存进行读写的人来说，这与发出的代码不太一致。在我对这个问题的回答中，我展示了使用和不使用volatile的代码的反汇编。在循环中，所有内容都保存在寄存器中。唯一显著的差异似乎是寄存器选择。我不太了解x86汇编，不知道为什么非易失性版本的性能一直很快，而易失性版的性能却一直很慢（有时甚至非常慢）。

Answer 1

Volatile确保一件事，而且只有一件事：每次从内存中读取易失性变量的读数 - 编译器不会假设该值可以缓存在寄存器中。同样，写入将被写入内存。编译器不会将其保存在寄存器中“一段时间，然后将其写入内存”。

为了防止编译器重新排序，您可以使用所谓的编译器Geofence。MSVC包括3个编译器Geofence：

_ReadWriteBarrier（）-全Geofence

_ReadBarrier（）-用于装载的双面Geofence

_WriteBarrier（）-商店的双面Geofence

国际刑事法院包括__memory_barrier（）全Geofence。

全栅栏通常是最好的选择，因为在这个层次上不需要更精细的粒度(编译器栅栏在运行时基本上是无成本的)。

状态重新排序（大多数编译器在启用优化时都会这样做），这也是某些程序在使用编译器优化编译时无法操作的主要原因。

将建议阅读 http://preshing.com/20120625/memory-ordering-at-compile-time，以了解编译器重构等我们可能面临的潜在问题。

Answer 2

防止重新排序的通常方法是一个编译障碍，即asm易失性（"::："内存"）；（使用gcc）。这是一条什么都不做的asm指令，但是我们告诉编译器它会破坏内存，所以不允许跨它重新排序代码。这样做的成本只是删除重新排序的实际成本，这显然不是像其他地方建议的那样改变优化级别等的情况。

我相信_ReadWriteBarrier相当于微软的东西。

根据Maxim Yegorushkin的回答，重新排序不太可能是你的问题的原因。

Answer 3

一位同事指出，我应该将start和stop变量声明为volatile，以避免代码重新排序。

很抱歉，但您的同事错了。

编译器不会对定义在编译时不可用的函数调用进行重新排序。想象一下，如果编译器将这些调用重新排序为< code>fork和< code>exec,或者在这些调用周围移动代码，会有多么有趣。

换句话说，任何没有定义的函数都是编译时内存障碍，即编译器不会在调用前移动后续语句或调用后移动先前语句。

在对 std：：clock 的代码调用中，最终会调用其定义不可用的函数。

我不能推荐足够的观看原子武器:C内存模型和现代硬件，因为它讨论了关于(编译时)内存障碍和< code>volatile以及许多其他有用的东西的误解。

然而，我添加了volatile，发现不仅基准测试花费的时间明显更长，而且每次运行之间也非常不一致。没有volatile(幸运的是确保代码没有被重新排序)，基准测试持续花费600-700 ms。使用volatile，通常花费1200 ms，有时超过5000 ms

不确定易失性是否是罪魁祸首。

报告的运行时间取决于基准是如何运行的。确保禁用CPU频率缩放，以便它不会在运行过程中打开turbo模式或切换频率。此外，微基准应该作为实时优先级进程运行，以避免调度噪声。可能在另一次运行中，一些后台文件索引器开始与您的基准竞争CPU时间。更多细节见此。

一个好的做法是测量多次执行函数所需的时间，并报告min/avg/median/max/stdev/total时间数。高标准偏差可能表明未进行上述准备。第一次运行通常是最长的，因为CPU缓存可能是冷的，它可能会出现许多缓存未命中和页面错误，并且在第一次调用时也会从共享库中解析动态符号（例如，在Linux上，延迟符号解析是默认的运行时链接模式），而后续调用将以更少的开销执行。