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

Subject: Re: [Boost-users] [Interval] Help debugging compiler optimization
From: Mário Costa (mario.silva.costa_at_[hidden])
Date: 2018-03-07 17:43:29

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 listBoost-users_at_[hidden]https://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>
> --
> Tim van Erven <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
>
>