定时与“假设"对比规则 [英] Timing vs the "as-if" rule

问题描述

关于按原样"的问题，有一个很大的疑问.规则，但是我想知道在测量时间方面是否有例外情况.

There is a great question about the "as-if" rule in general, but I wonder if there are any exceptions when it comes to measuring time.

考虑一下(取自此处稍作修改):

Consider this (taken from here slightly modified):

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 结果的优化.这里的要点是，假设"规则不适用于直接测量的时间.当然，在应用优化时，测得的时间不应是恒定的.

The compiler is allowed to apply any optimization that results in the same result. The point here is that the "as-if" rule does not apply to the measured time directly. Of course the measured time is not something that should be constant when optimizations are applied.

所以我的问题是:根据假设"条件，我怎么可能用上述代码可靠地测量时间.规则，允许编译器将其重新排列为以下之一?

So my question is: How is it possible that I can reliably measure time with the above code when, according to the "as-if" rule, the compiler is allowed to rearrange it to one of the following?

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);

我认为没有理智的编译器会这样做，但是究竟是什么阻止了编译器进行这种优化"呢?

I assume no sane compiler would do that, but what exactly prevents a compiler from doing such "optimization"?

TL; DR ...

• 人们可以观察到优化后的代码与未优化后的代码之间的运行时差异
• 如果允许编译器优化影响所测时间，是什么阻止了编译器根本不为时序创建任何代码?

推荐答案

要应用假设"规则，编译器必须证明建议的更改对可观察的行为没有影响.您是正确的，时间的流逝不是可观察的行为.但是，在对函数进行重新排序的情况下，必须证明函数的调用顺序不会影响可观察到的行为.

For the As-If rule to apply, the compiler must prove that the proposed change has no impact on the observable behavior. You are correct that the passage of time is not an observable behavior. However, in the case of reordering functions, it must prove that the order the functions are called in doesn't impact the observable behavior.

使用计时功能将始终包含一些用于测量时间的机制，编译器将无法证明这种机制可以安全地重新排序.例如，它可能涉及对无法检查的不透明系统API函数或驱动程序函数的调用.如果我们以最透明的示例为例，单调的软件时钟在每次进入状态时仅前进1个单位时间，则无法证明呼叫顺序无关紧要，因为它确实很重要.

Using timing features will invariably involve some mechanism for measuring time which the compiler will not be able to prove is safe to reorder. For example, it might involve a call to an opaque system API function or driver function that it can't inspect. If we take the most transparent example, a monotonic software clock that simply advances by 1 unit of time every time it's state is taken, there's no way to prove that the call order doesn't matter because it does matter.

这篇关于定时与“假设"对比规则的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！