Why Fortran Composer XE 2013 has optimization option /nofltconsistency as default?

Why Fortran Composer XE 2013 has optimization option /nofltconsistency as default?

My company is migrating from Fortran 10 to Fortran Composer XE 2013 and we're getting multiple failures in our regresssion tests. Many working hours were spent in attempts to localize the source of errors until we noticed that the option /nofltconsistency was default. After setting it to /fltconsistency all errors went away.
I understand the striving to make compiler code faster but why to do this at the expense of accuracy?  Developers of source codes from netlib.org worked in XX century when no one could divine what the future with /nofltconsistency will  be like. I also understand  the importance of RTFM but information about   /fltconsistency is buried deep in user guide: Compatibility and Portability/Understanding Fortran Language Standards/Using Compiler Optimizations.
I'd suggest to make  /fltconsistency  default option for future updates and to improve visibility of this option in documentation.

 

 

11 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

It's not a case of "accuracy". With floating point, any change in the order of operations, including optimizations such as vectorization, can cause small changes in the results. For most applications, this doesn't matter and trying to reduce inconsistency significantly reduces performance. Many times, programs print out results to far more decimal places than the input data's precision or the calculations warrant.

We do have a variety of options that can help you control how the compiler deals with floating point. /fltconsistency is an old option not recommended for use. We suggest instead that you look at the /fp option to see if one of the choices there is right for you.

Steve - Intel Developer Support

Unfortunately, what we have is not "small changes in the results". We have full blown crashes.

A bit harsh, but your code/algorithms can't be that robust if accumated prescision causes it to crash, some relevant error checking must be absent for example.

Floating point consistency and floating point accuracy are not the same thing, even though they may be related. Therefore, one may question the usefulness of regression tests that rely too much upon consistency being used as a proxy for accuracy.

There is a file called ifort.cfg that the command line compiler reads. Intel Fortran is quite good at understanding and honoring compiler options across many versions of the compiler. You can maintain a set of options suitable for your needs in this file and reuse the file following compiler updates. Since options listed in this file override default options, you can obtain some immunity against unpleasant surprises arising from changes in the default options when new versions of the compiler are released.

We have crashes in various netlib.org codes that  never caused any problems. These codes have multiple checks in them (nnes.for, zbsubs.f) and I see crashes in these checks.

What do you mean by "crashes"? I can't recall seeing complaints about netlib in general.

Steve - Intel Developer Support

Steve, we wrap Fortran static library in C++ dll that provide access to fortran functions via interfaces. When running netlib.org nnes.for and modified Bessel functions from zbsubs.f (with Fortran default optimization options) via interface we get what we call "unexpected exception", that is hard crash, so I cannot say exactly what happens. 
I tried /fp:strict in Fortran static library project and that allowed to get rid of hard crashes. However, I still see 1% differences in some regression tests with our own Fortran code. Option /fltconsistency allows to get rid of both hard crashes and differences in regression tests.

 

 

 

I can fully empathise with the original poster's situation.

I've encountered something similar that shows up when the /fp:fast compiler option is active. Note that /fp:fast seems to be the default setting. The program that I've been working on produces gravely incorrect results with the /fp:fast option active. I've narrowed this down in a short example program in another post that demonstrates the issue. Note that the problem is not small differences in accuracy. It's the difference between one value being 0.0 and another being 0.5, dependent on whether /fp:fast is active or not.

sdaylis, if you are getting an exception, then something is wrong. Please work with us to help identify it. Are you willing to provide a copy of the application sources and project to Intel Premier Support?

Steve - Intel Developer Support

If I succeed to downsize the problem and to reproduce it in pure Fortran project I'll file the issue.

Leave a Comment

Please sign in to add a comment. Not a member? Join today