Re: [Boost-users] [Interval] Help debugging compiler optimization

Subject: Re: [Boost-users] [Interval] Help debugging compiler optimization
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2018-03-08 09:42:50

Would it help to use 

 

constexpr double v1 and constexpr computation,

 

to see what the compiler can compute at compile-time

 

and to use a better print method

 

std::cout.precision(std::numeric_limits<double>::max_digits10);  

 

std::cout << v1 << “ “ << computation << std::endl;

 

to see the ‘true’ results of both your doubles?

 

godbolt.org  may also help you see what assembler is produced.

 

Paul

 

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]
 
 
From: Boost-users [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Tim van Erven via Boost-users
Sent: 08 March 2018 08:36
To: Mário Costa; boost-users_at_[hidden]
Cc: Tim van Erven
Subject: Re: [Boost-users] [Interval] Help debugging compiler optimization
 
Hi Mário,
My (somewhat naive) view of compilers is that they can only do optimization that has no visible effects on the behavior of the program.
What I meant is:
double v1 = 1.0/3.0;
printf("%f", v1);
double computation = v1 * 3;
Then the print statement will show the user some value for v1 that fits in a double. So I would expect that it is then no longer free to treat v1 as exactly 1/3, because the use has already observed a different value.
Best,
  TIm
On 07/03/2018 18:43, Mário Costa wrote:
I don't really understand what you mean.
lets say you have
double v1 = 1.0/3.0;
double computation = v1 * 3;
Using, O2, the compiler might resolve, by performing expression analisys at compile time, that you have always a constant value of 1/3 * 3 = 1.
Now using O0, it might not optimize, and compute the value at runtime (just as an example).
Because 1/3 does not fit into any number of bits without lossing precision (unless you'd be using some symbolic library), multiplying v1 * 3, will result in a value diferent from 1, that will be the rule.
Another issue Degski mentions, its the error propagation associated with the order the expressions are evaluated/executed ...
 
 
On Wed, Mar 7, 2018 at 5:09 PM, Tim van Erven via Boost-users <boost-users_at_[hidden]> wrote:
Hi Degski,
But if I assign 1/3 to a double and then print that to the console, then I would expect the compiler to be committed to the value shown in the console, but apparently it isn't, and still does optimization.
Best,
  Tim 
 
On 07/03/2018 15:53, Mário Costa via Boost-users wrote:
Not sure this "random" aswer explains it:
1/3 it's a recurring decimal (https://en.wikipedia.org/wiki/Repeating_decimal), that means it is not possible to represent it within a limited number of bits (even in 64 bits).
So your "bug" example, I would say that it's not a bug. Using optimization in one of the cases the compiler can figure out, that the value is 1, by analyzing constant values assigned to v2 and lazy expanding the expression (template expansions, etc), (which is correct math value).
The other option v1, uses memory storage, and because of that, it cannot lazy expand the expression at the function call, so because you cannot store 1/3 perfectly in 64 bits, after multiplying it, it always results in a number lower 1.
 
On Wed, Mar 7, 2018 at 11:54 AM, degski via Boost-users <boost-users_at_[hidden]> wrote:
On 6 March 2018 at 20:43, Nathan Ernst via Boost-users <boost-users_at_[hidden]> wrote:
This does feel like a floating-point optimization switch, though, at least to me.
 
Additionally, the optimization level it self could interfere with the order of calculation, leading to possibly different results.
degski
_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
 
_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
-- 
Tim van Erven  <mailto:tim_at_[hidden]> <tim_at_[hidden]>
www.timvanerven.nl
_______________________________________________ Boost-users mailing list Boost-users_at_[hidden] https://lists.boost.org/mailman/listinfo.cgi/boost-users 
-- 
Tim van Erven  <mailto:tim_at_[hidden]> <tim_at_[hidden]>
www.timvanerven.nl