4 ms·

If you think about how it interacts with inlining, it's easy to see how optimizers like this freedom. Suppose there's just one call that may throw and the other

If you think about how it interacts with inlining, it's easy to see how optimizers like this freedom. Suppose there's just one call that may throw and the others are pure functions. The compiler could bunch the pure ones together to optimize register and stack allocation.

atq2119 5y ago
This is the correct answer, plus add loop unrolling etc. It is simply not possible to write an optimizing compiler in which the evaluation order is truly indeterminate yet always the same.
- tsimionescu 5y ago
  I was claiming it could be left implementation defined instead of unspecified. That way, code for particular platforms could be evaluated in different order, but it would always be deterministic for a particular compiler.
  - vnorilo 5y ago
    The optimized evaluation order would depend on the situation near at the call site, not the architecture or platform.
    - tsimionescu 5y ago
      The GP that my post was replying to was claiming it was arch dependent, and I was pointing out that, if it had been, they would have likely not left it unspecified. So, I think you and I are in agreement.
tsimionescu 5y ago
I would be truly shocked if this optimization ever mattered in practice. It would mean that rewriting code from { auto& a = <expression> auto& b = <expression> foo(a, b); } To foo(<expression>, <expression>); Could be an optimization. Edit: modified the code a bit to make the two samples more similar.
- gpderetta 5y ago
  During the standardization of C++17, a proposal specifying the left-to-right order of evaluation of parameters (and other operations) came up and the committee got very close to accepting it, but in the end there were concrete examples in actual code that was worse of because of the proposal, so it was unfortunately weakened at the last minute.
  - simiones 5y ago
    Looking at the proposal in question [0], it seems very sad that the alternate, not recommended, choice was made instead [1] , especially since the reasoning seems to have not been put down in writing anywhere. The paper does mention that the difference in performance was <4%, with both improvements and worsening being seen by the VC++ implementers. [0] http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0145r3.pdf http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0145r3.... [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0400r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p040...
- vnorilo 5y ago
  Why shocked? Certainly a micro-optimization, but order of things often matters if the compiler cannot prove it's safe to speculate about the execution order. Maybe the surprising thing here is the theme of TFA, that the order of argument evaluation is not defined.
  - simiones 5y ago
    Given the out of order nature of processors, and the relatively limited scope for complex expressions given as function arguments, I would not expect this to matter in real-world programs. It seems this was also the opinion of the people drafting the new evaluation order changes [0] in C++17: > We do not believe that such a nondeterminism brings any substantial added optimization benefit, but it does perpetuate the confusion and hazards around order of evaluations in function calls.It perpetuates unnecessary confusion around brace-initialization vs. direct initialization using parenthesis. > We found that some entries in the benchmark suite ran slower, others ran faster compared to the scenario where the evaluation of the argument list is left unspecified. The variation is between -4% and +4%. It is worth noting that these results are for the worst case scenario where the optimizers have not yet been updated to be aware of, and take advantage of the new evaluation rules and they are blindly forced to evaluate function calls from left to right. It is clear that the left-to-right evaluation strategy is triggering new optimization paths (different inlining decisions and different register allocation) affecting the variations in the benchmark performance. It appears those opportunities have not traditionally been exploited, even though permitted under the unspecified order regime. Unfortunately, they seem to have been overruled by the Core Working Group [1], for reasons I have not been able to dig up. [0] http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0145r3.pdf http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0145r3.... [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0400r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p040...

atq2119 5y ago

This is the correct answer, plus add loop unrolling etc. It is simply not possible to write an optimizing compiler in which the evaluation order is truly indeterminate yet always the same.

tsimionescu 5y ago
I was claiming it could be left implementation defined instead of unspecified. That way, code for particular platforms could be evaluated in different order, but it would always be deterministic for a particular compiler.
- vnorilo 5y ago
  The optimized evaluation order would depend on the situation near at the call site, not the architecture or platform.
  - tsimionescu 5y ago
    The GP that my post was replying to was claiming it was arch dependent, and I was pointing out that, if it had been, they would have likely not left it unspecified. So, I think you and I are in agreement.

tsimionescu 5y ago

I would be truly shocked if this optimization ever mattered in practice. It would mean that rewriting code from { auto& a = <expression> auto& b = <expression> foo(a, b); } To foo(<expression>, <expression>); Could be an optimization. Edit: modified the code a bit to make the two samples more similar.

gpderetta 5y ago
During the standardization of C++17, a proposal specifying the left-to-right order of evaluation of parameters (and other operations) came up and the committee got very close to accepting it, but in the end there were concrete examples in actual code that was worse of because of the proposal, so it was unfortunately weakened at the last minute.
- simiones 5y ago
  Looking at the proposal in question [0], it seems very sad that the alternate, not recommended, choice was made instead [1] , especially since the reasoning seems to have not been put down in writing anywhere. The paper does mention that the difference in performance was <4%, with both improvements and worsening being seen by the VC++ implementers. [0] http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0145r3.pdf http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0145r3.... [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0400r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p040...
vnorilo 5y ago
Why shocked? Certainly a micro-optimization, but order of things often matters if the compiler cannot prove it's safe to speculate about the execution order. Maybe the surprising thing here is the theme of TFA, that the order of argument evaluation is not defined.
- simiones 5y ago
  Given the out of order nature of processors, and the relatively limited scope for complex expressions given as function arguments, I would not expect this to matter in real-world programs. It seems this was also the opinion of the people drafting the new evaluation order changes [0] in C++17: > We do not believe that such a nondeterminism brings any substantial added optimization benefit, but it does perpetuate the confusion and hazards around order of evaluations in function calls.It perpetuates unnecessary confusion around brace-initialization vs. direct initialization using parenthesis. > We found that some entries in the benchmark suite ran slower, others ran faster compared to the scenario where the evaluation of the argument list is left unspecified. The variation is between -4% and +4%. It is worth noting that these results are for the worst case scenario where the optimizers have not yet been updated to be aware of, and take advantage of the new evaluation rules and they are blindly forced to evaluate function calls from left to right. It is clear that the left-to-right evaluation strategy is triggering new optimization paths (different inlining decisions and different register allocation) affecting the variations in the benchmark performance. It appears those opportunities have not traditionally been exploited, even though permitted under the unspecified order regime. Unfortunately, they seem to have been overruled by the Core Working Group [1], for reasons I have not been able to dig up. [0] http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0145r3.pdf http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0145r3.... [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0400r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p040...