4

关于一般的“as-if”规则有一个很大的问题，但我想知道在测量时间方面是否有任何例外。

考虑一下（取自此处稍作修改）：

using std::chrono;
auto begin = steady_clock::now();

auto result = some_lengthy_calculation(some_params);

auto end = std::chrono::steady_clock::now();

std::cout << "Time diff = " << duration_cast<microseconds>(end - begin).count() <<std::endl;
std::cout << "Result = " << result;

允许编译器应用任何产生相同结果的优化result。这里的重点是“as-if”规则并不直接适用于测量时间。当然，在应用优化时，测量的时间不应该是恒定的。

所以我的问题是：当根据“as-if”规则允许编译器将其重新排列为以下之一时，我怎么可能用上面的代码可靠地测量时间？

auto temp = some_lengthy_calculation(some_params); // clever "optimization", precompute some stuff

auto begin = steady_clock::now();
auto result = temp;               // yay, I can use it here to pretend to be faster
auto end = steady_clock::now();

std::cout << "Time diff = " << duration_cast<microseconds>(end - begin).count() <<std::endl;
std::cout << "Result = " << result;

甚至“更优化”：

std::cout << "Time diff = " << 42 <<std::endl;
std::cout << "Result = " << some_lengthy_calculation(some_params);

我假设没有理智的编译器会这样做，但是究竟是什么阻止了编译器进行这种“优化”呢？

TL;博士...

  • 可以观察优化代码和非优化代码之间的运行时差异
  • 如果允许编译器优化影响测量时间，是什么阻止编译器根本不为计时创建任何代码？
4

2 回答 2

2

编译器不会那样做，你可以确定。

虽然在纯理论中，获取系统时间涉及系统调用，但对于编译器来说，这是一个完整的黑匣子。

编译器不能围绕黑盒函数调用重新排序，因为它不能假设这不会有任何副作用或包含任何障碍。

于 2017-10-04T19:50:45.947 回答
2

要应用 As-If 规则，编译器必须证明提议的更改对可观察行为没有影响。你是对的，时间的流逝不是一种可观察的行为。但是，在重新排序函数的情况下，它必须证明调用函数的顺序不会影响可观察的行为。

使用计时功能总是会涉及一些用于测量时间的机制，编译器将无法证明重新排序是安全的。例如，它可能涉及对无法检查的不透明系统 API 函数或驱动程序函数的调用。如果我们举一个最透明的例子，一个单调的软件时钟，每次获取它的状态时简单地前进 1 个单位时间，没有办法证明调用顺序无关紧要，因为它确实很重要。

于 2017-10-04T19:51:10.427 回答