4 ms·

There are two things about the C++: 1) why use a class for the timer? 2) It's not clear if the order of operations ensures that the timer is stopped before th

by veyron 14y ago

There are two things about the C++: 1) why use a class for the timer? 2) It's not clear if the order of operations ensures that the timer is stopped before the first print operation happens. Thus your C++ may be including some part of the cout print operation

jamesaguilar 14y ago
Re: 2, I am surprised if operations with side-effects get called out of order.
- veyron 14y ago
  Site's down, so I can't pull up the exact link, but the java code basically did get time do it get time again print timing info The C++ code had a line of the form cout << .... << some_method_which_stops_time_and_returns << ... So unless G++ is doing some sort of whole program analysis, it would have to do the cout << ... first and then evaluate the method and then print out the return value
  - Wilya 14y ago
    Code is at https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/tree/master/2012/07/23 https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/... Fwiw, I just ran it after fixing the time call, and it doesn't seems to significantly change the result on my (low spec) machine.
  - Symmetry 14y ago
    Here's the link to the github account where the code is: https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/tree/master/2012/07/23 https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/... Even if they're doing whole program analysis, the fact that oeprator<<() and WallClockTimer.split() are side-effectful and I believe that means that it would be invalid for the compiler to find the current time before the first section of the print statement is finished.
  - repsilat 14y ago
    Evaluation order is implementation-defined. I'm pretty sure all of the arguments are evaluated before any printing is done at all. The code cout << "asdf:" << b() is equivalent to (cout << "asdf:") << b() , which is equivalent to cout.operator<<("asdf:").operator<<(b()) `b()` can certainly be evaluated before the first `operator<<` is evaluated. Hell, `b()` can be evaluated before "asdf;" is evaluated. Consider the following code: int f() { static int a=0; return a++; } cout << f() << " " << f() << endl; This prints "0 1" in Clang (at all levels of optimisation), and it prints out "1 0" in gcc (again, at all levels of optimisation). If they're differing on something as simple as this it's clearly allowable by the standard.
  - scott_s 14y ago
    Sorta, yes. It can evaluate one of the operator<<'s before doing the timer. The following: cout << "smarter sum " << N/(1000.0*time.split()) << endl; Is semantically equivalent to: operator<<(endl, operator<<(N/1000.0*time.split(), operator<<(cout, "smarter sum ") ) ); The code with the timer in it can be called after the first call to operator<<; all parameters to functions have to be evaluated before the function is called, but there's no order the parameters themselves have to be evaluated in.

by veyron 14y ago

jamesaguilar 14y ago

Re: 2, I am surprised if operations with side-effects get called out of order.

veyron 14y ago
Site's down, so I can't pull up the exact link, but the java code basically did get time do it get time again print timing info The C++ code had a line of the form cout << .... << some_method_which_stops_time_and_returns << ... So unless G++ is doing some sort of whole program analysis, it would have to do the cout << ... first and then evaluate the method and then print out the return value
- Wilya 14y ago
  Code is at https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/tree/master/2012/07/23 https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/... Fwiw, I just ran it after fixing the time call, and it doesn't seems to significantly change the result on my (low spec) machine.
- Symmetry 14y ago
  Here's the link to the github account where the code is: https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/tree/master/2012/07/23 https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/... Even if they're doing whole program analysis, the fact that oeprator<<() and WallClockTimer.split() are side-effectful and I believe that means that it would be invalid for the compiler to find the current time before the first section of the print statement is finished.
- repsilat 14y ago
  Evaluation order is implementation-defined. I'm pretty sure all of the arguments are evaluated before any printing is done at all. The code cout << "asdf:" << b() is equivalent to (cout << "asdf:") << b() , which is equivalent to cout.operator<<("asdf:").operator<<(b()) `b()` can certainly be evaluated before the first `operator<<` is evaluated. Hell, `b()` can be evaluated before "asdf;" is evaluated. Consider the following code: int f() { static int a=0; return a++; } cout << f() << " " << f() << endl; This prints "0 1" in Clang (at all levels of optimisation), and it prints out "1 0" in gcc (again, at all levels of optimisation). If they're differing on something as simple as this it's clearly allowable by the standard.
- scott_s 14y ago
  Sorta, yes. It can evaluate one of the operator<<'s before doing the timer. The following: cout << "smarter sum " << N/(1000.0*time.split()) << endl; Is semantically equivalent to: operator<<(endl, operator<<(N/1000.0*time.split(), operator<<(cout, "smarter sum ") ) ); The code with the timer in it can be called after the first call to operator<<; all parameters to functions have to be evaluated before the function is called, but there's no order the parameters themselves have to be evaluated in.