Problem with /fp:fast vs /fp:precise

[sarabjyot]

I have a huge fortran code which I am compiling using Visual studio 2005 and Intel fortran 9.1. I have tried different floating point options and currently I am faced with a problem with /fp:fast and /fp:precise options, along with /heap-arrays as option. With the fast option the code works fine, while with the precise option it crashes giving me divide by zero and producing NANs. Also the problem is arrising much later in the run so tracking it down in such a huge code is becoming a daunting task. I am using the precise option to maintain the consistency between the debug and release mode for Intel fortran.

The results from both these options initially is the same but becomes much different as the run progresses. Is it because the rouding off error is accumulating? I would appreciate an early reply as I have a deadline to meet.

[Ron_Green]

Quoting - sarabjyot@gmail.com

I have a huge fortran code which I am compiling using Visual studio 2005 and Intel fortran 9.1. I have tried different floating point options and currently I am faced with a problem with /fp:fast and /fp:precise options, along with /heap-arrays as option. With the fast option the code works fine, while with the precise option it crashes giving me divide by zero and producing NANs. Also the problem is arrising much later in the run so tracking it down in such a huge code is becoming a daunting task. I am using the precise option to maintain the consistency between the debug and release mode for Intel fortran.

The results from both these options initially is the same but becomes much different as the run progresses. Is it because the rouding off error is accumulating? I would appreciate an early reply as I have a deadline to meet.

Yes, /fp-model:precise is the more accurate answer, and yes, what you see with :fast is the error accumulating over time.

If you have time for an analysis you'll want to turn on all checking with options such as

/fp-model:precise /Qfp-stack-check /fpe:0 /Zi /traceback /check:all

[TimP]

If you are permitting SSE vectorization, the most likely case for /fp:fast to show reduced growth of roundoff, compared with /fp:precise, is in vectorized sum reduction (including dot product and matmul). If you are avoiding SSE, there is potential for more automatic promotion of expressions from single to double precision with /fp:fast, which could be quite effective in controlling round off error accumulation.

[Wendy_Doerner__Intel]

I have been working with this customer through our support channels, but without a test case it seems the suggestions above are our best hope in troubleshooting this error. Note the 9.1 compiler is no longer supported and a first suggestion would be to upgrade to the latest compiler where any bugs with our fp_model will have been fixed.

With a current support contract, here are instructions on how to get the latest release:

http://software.intel.com/en-us/articles/product-download/