3 ms·

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 h

by 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

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.