[RndTbl] Problem with g++ optimization

[Dan Martin]

Thanks for the advice, Sean.

I suspect it's an issue of double precision, but I cannot find what 
specific flags are involved.

Image colum from original program, unknown compiler optimizations:
  0:  9.40411e-05
  1:  0.000374236
  2:  0.000421015
  3:  0.000158423
  4:  0.000421016
  5: -6.64318e-05
  6:  0.000225337

Image colum from my program, no compiler optimizations:
  0:  9.40411e-05
  1:  0.000388825
  2:  0.000421015
  3:  0.000158423
  4:  0.000421016
  5:  0.000374236
  6:  0.000356633

Difference:
  0:            0
  1: -1.45885e-05
  2:            0
  3:            0
  4:            0
  5: -0.000440668
  6: -0.000131296

Percentage wise, these differences can be quite significant.
If  I compile a single file from my version of the program 
(backprojectors.cpp) with the -O2 option, the differences disappear.
I combined all of the options that the gcc man page said were included 
in -O1 and -O2, and the differences did NOT disappear, so I still don't 
know what specific options are making the difference in the original 
program.

Sean Cody wrote:

> From gcc man page...
>
>            Important notes: -ffast-math results in code that is not  
> necessar-
>            ily IEEE-compliant.  -fstrict-aliasing is highly likely  
> break non-
>            standard-compliant programs.  -malign-natural only works  
> properly
>            if the entire program is compiled with it, and none of  the 
> standard
>            headers/libraries contain any code that changes alignment  
> when this
>            option is used.
>
> If you are having precision issues with the doubles kill the above  
> flags with your optimizations (eg. -fno-fast-math).
> I'm going to assume that v is global so it may not be scoping and  
> from your description it _sounds_ more like precision issues.
> If it is precision issues start turning off selectively the options  
> from the optimized flags and find out which one is mucking up the  
> results.
>
> I wouldn't assume it is the code generated until you can prove it by  
> finding a particular optimization strategy which is producing the issue.
> In integer only cases I would argue the compiler is outputting  
> correct code but with reals the size/space optimizations can do a  
> _whole lot_ of damage.
>
> If the values are within a valid range I would suggest liberal  
> application of assertions, it is hard to say what you mean by correct  
> values but if the numbers are off by a certain amount or are rounded  
> up or down from what you expect then I would put money on precision  
> issues.
>

-- 
  -Dan

Dr. Dan Martin, MD, CCFP, BSc, BCSc (Hon)

GP Hospital Practitioner
Computer Science grad student
ummar143 at cc.umanitoba.ca