Large differences between 01 and 02/03

[cr362]

Hi, I have a quick question regarding optimisation.

Essentially, I'm getting large differences when I compile with O1 compared to O2/O3 (O2 and O3 produce very similar results).

I'm not using any other compile options - only O1 or O2/O3.

I don't think the differences are due to small rounding errors - when I optimise using 01 I get a result of 0.623424, but when I optimise with 02/03 I'm getting a result of 7.345743 (i.e. more than just a rounding error).

I've tested the code with -check bounds etc., but everything appears OK.

Anyone know what this could be? Or have any tips on how I can solve the issue?

Many Thanks.

[Ron_Green]

try -fpmodel precise -O2

and -fpmodel strict -O2

If these give results similar to -O1 then you do have some research to do.

ron

[cr362]

Hi Ron, Thanks for your quick reply.

fp-model precise and strict (when run with -O2) give 3.145624

This is different to O1.

Strange, I'm really confused by this!

[Martyn_C_Intel]

For completeness, you should also run with -O1 -fp-model precise, andconfirm thatthis result is different from your result with -O2 -fp-model precise above. Assuming it is different, that confirms your original assertion that this is not due to the accumulation of rounding errors. (Whilst that would be pretty unlikely to cause such large differences, I have seen examples involving large cancellations where this happened).

This would strongly suggest a compiler bug in optimization, though it wouldn't exclude certain types of coding error (involving uninitialized variables, for example).

Much the best would be if you could provide us with a compilable and executable example that produced different results at different optimization levels. We could theninvestigate and determine the cause. If that's not possible, we can suggest ways for you to narrow down the source of the problem, but that will be slower and harder. Either way, the first step would be to find out which source file is responsible, ie the app works when this file is compiled at -O1 but not when it is compiled at -O2.

Please also let us know which compiler version you are using. I am aware of one issue with similar symptoms that occurs at -O2 but not -O1 for a particularcombination of constructsthat was fixed in the recently released update 6 to the 11.1 compiler (for Linux, l_cprof_p_11.1.072).

[mecej4]

The symptoms described made me wonder if this is another instance of the optimizer bug that I reported in Thread 73629.

It would be nice to have the actual code for a small example that would enable one to reproduce the problem.

[jimdempseyatthecove]

How do you know the difference between 0.623424 and 7.345743 is other than a rounding error?

The above could be the result of a small difference in very large magnitude numbers.
The above could be the result of a very large number of accumulations of very small differences.

You will have to look at the math to determine if the difference is significant.

Are you using REAL(8) or REAL(4)?

If using REAL(4), see if you can easily switch part of or most of the calculations over to REAL(8). Then check the run time differences in your results. If this difference is diminished by 10 decimal places then this is indicative that you had a rounding error (possibly due to either of the above two situations).

If you are using REAL(8) or after change the difference is large, then assume in this order

programming error
compiler error

programming error is the most likely source of error.

One of the first causes for spurious errors in results is use of un-initialized variables. (e.g. assuming uninitialized == 0.0)

A second common cause is argument calling errors.

The compiler and run-time system has tests for both of these common errors. Have you used these options?

Jim Dempsey