Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28385 Discussions

Question about fp:source vs fp:precise vs fp:consistent

Christopher_M_1
Beginner
1,942 Views

Hi,

So I have been doing some research into the floating point model options and based on the various bits of documentation, I am very confused about what combinations are really recommended.  For example:

Looking at the following document:

https://software.intel.com/sites/default/files/managed/de/a1/FP_Consistency_091117.pdf

It says on page 19:

"Use /fp:precise /fp:source (Windows) or -fpmodel precise -fp-model source (Linux or OS X) to improve the consistency and reproducibility of floating-point results while limiting the impact on performance"

Then in a parenthetical remark, it says that fp:source implies fp:precise.

So my question is this:  if using fp:source also gets you the behavior of setting fp:precise, then why is the recommendation to use both of those settings on the command line?  Isn't it enough to just set fp:source and be done with it?

Similarly, the document says:

"The geomean of the performance reduction due to -fp-model consistent -fp-model source was about 12%"

but later on says that engaging fp:consistent sets "all of the above options", which presumably includes fp:source.  So if that is indeed true, then why does the document go to the trouble of mentioning that both -fp-model consistent and -fp-model source were used together?  This makes me question whether fp:source is adding some extra behavior beyond what fp:consistent gives you.

One additional question:  to maximize consistency between platforms/chip architectures is the current recommendation to simply set /fp:consistent for Intel 17 and Intel 18 compilers or are there additional settings I should also be looking at?

Any insight would be greatly appreciated.

Chris

 

0 Kudos
1 Solution
Martyn_C_Intel
Employee
1,942 Views

In principle, /fp:source, /fp:double and /fp:extended control the intermediate precision for expression evaluation and are orthogonal to /fp:fast, precise, except, strict and consistent. However, as Steve indicates, this is only relevant to C or C++ (and is more important for IA-32 than Intel64). For technical reasons, only "source" is supported for expression evaluation in Fortran; therefore, you can safely ignore /fp:source and use only /fp:precise or consistent. The article you quote applies to both C/C++ and Fortran, so needs to mention source, double and extended. We try to make the switches and article accurate and logically consistent, but I understand that may be a bit confusing for Fortran where /fp:source doesn't do anything (except imply -fp-model precise if that wasn't set separately).

       The context in which setting /fp:source as well as /fp:precise is important is for C/C++ on IA-32. Here, the default is "double" on Windows and "extended" on Linux, which gives best performance, but "source" gives the best consistency. On Intel64, "source" is the default and normally also gives best performance, so the other options, though supported for C/C++, are relatively unimportant. The architects like to encourage thinking of the expression evaluation method separately from reproducibility (value safety etc.), so like to use an explicit switch for each. But it's true that /fp:source isn't really adding anything for Fortran (or even for C/C++ on Intel64).

 

Yes, /fp:consistent is the recommendation for best consistency between different processors (microarchitectures) or different optimization levels. It is equivalent to /fp:precise /Qfma- /Qimf-arch-consistency:true, but was introduced in the version 17 compile as a "one stop" option for getting reproducible results that would be clearer to document and easier to find.

This should give consistency between different microarchitectures and instruction sets, such as SSE and AVX, but not necessarily between different architectures such as IA-32 and Intel64. It also does not necessarily ensure consistency between different major compiler versions - there could be improved versions of some math functions giving results that were more accurate, but different.

Hope this helps.

View solution in original post

0 Kudos
7 Replies
Steve_Lionel
Honored Contributor III
1,943 Views

For C++, "source" and "precise" do different things, for Fortran they don't.  For C++ it may be worth setting both those options, but for Fortran it isn't.

Perhaps Martyn Corden, one of the article authors, will step in to explain further.

0 Kudos
Martyn_C_Intel
Employee
1,943 Views

In principle, /fp:source, /fp:double and /fp:extended control the intermediate precision for expression evaluation and are orthogonal to /fp:fast, precise, except, strict and consistent. However, as Steve indicates, this is only relevant to C or C++ (and is more important for IA-32 than Intel64). For technical reasons, only "source" is supported for expression evaluation in Fortran; therefore, you can safely ignore /fp:source and use only /fp:precise or consistent. The article you quote applies to both C/C++ and Fortran, so needs to mention source, double and extended. We try to make the switches and article accurate and logically consistent, but I understand that may be a bit confusing for Fortran where /fp:source doesn't do anything (except imply -fp-model precise if that wasn't set separately).

       The context in which setting /fp:source as well as /fp:precise is important is for C/C++ on IA-32. Here, the default is "double" on Windows and "extended" on Linux, which gives best performance, but "source" gives the best consistency. On Intel64, "source" is the default and normally also gives best performance, so the other options, though supported for C/C++, are relatively unimportant. The architects like to encourage thinking of the expression evaluation method separately from reproducibility (value safety etc.), so like to use an explicit switch for each. But it's true that /fp:source isn't really adding anything for Fortran (or even for C/C++ on Intel64).

 

Yes, /fp:consistent is the recommendation for best consistency between different processors (microarchitectures) or different optimization levels. It is equivalent to /fp:precise /Qfma- /Qimf-arch-consistency:true, but was introduced in the version 17 compile as a "one stop" option for getting reproducible results that would be clearer to document and easier to find.

This should give consistency between different microarchitectures and instruction sets, such as SSE and AVX, but not necessarily between different architectures such as IA-32 and Intel64. It also does not necessarily ensure consistency between different major compiler versions - there could be improved versions of some math functions giving results that were more accurate, but different.

Hope this helps.

0 Kudos
Thomas_F_1
Beginner
1,943 Views

Martyn Corden (Intel) wrote:

[...]

Yes, /fp:consistent is the recommendation for best consistency between different processors (microarchitectures) or different optimization levels. It is equivalent to /fp:precise /Qfma- /Qimf-arch-consistency:true, but was introduced in the version 17 compile as a "one stop" option for getting reproducible results that would be clearer to document and easier to find.

This should give consistency between different microarchitectures and instruction sets, such as SSE and AVX, but not necessarily between different architectures such as IA-32 and Intel64. It also does not necessarily ensure consistency between different major compiler versions - there could be improved versions of some math functions giving results that were more accurate, but different.

Hope this helps.

I realize this thread is a bit old, but I have been struggling with similar questions. And since we are "sheltering in place", I've been spending time investigating.

We currently compile with the Intel Fortran 2015 compiler (!) using `-fp-model source` and get bit-identical results across macOS, Linux, and Windows. I plan to move us to 2020 and change to `-fp-model consistent`. I can get bit-identical results between the 2015 and 2020 compilers if I add `-fimf-arch-consistency=true` to both compilers, but the results are not quite the same as our current reference solutions. So I'd like to understand what else has changed. The question is, is there a set of compiler options for 2020 that will give me equivalent behavior to only using `-fp-model source` with the 2015 compiler?

If the answer is "the math functions have changed", then how is it that I can get them to match with `-fimf-arch-consistency=true`?

Even if the answer is "you can't get them to match, and here is why..." would be sufficient for me to add to our ticket system. I've spent too many hours trying different FP options with no luck.

Thanks! And stay healthy.

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,943 Views

IMHO source and precise are not equivalent. While both sequence the expressions the same (with some latitude for scalar to vector), source is free to use the faster forms of intrinsic functions (sqrt, etc...) sacrificing precision for speed.

This needs to be pointed out better in the documentation (together, not in different places)

Jim Dempsey

0 Kudos
Steve_Lionel
Honored Contributor III
1,943 Views

There may not be any options that will match results from a different (older) compiler. Please see Improving Numerical Reproducibility in C/C++/Fortran

0 Kudos
Thomas_F_1
Beginner
1,943 Views

Steve Lionel (Ret.) (Blackbelt) wrote:

There may not be any options that will match results from a different (older) compiler. Please see Improving Numerical Reproducibility in C/C++/Fortran

 

Thanks Steve. I had read through your presentation before, along with Martyn's paper. I've also read through all of the release notes trying to understand what has changed. I suspect that it is related to changes in the 2018 release, but there isn't enough information to go on.

Take care.

0 Kudos
Steve_Lionel
Honored Contributor III
1,943 Views

It could be a change in the math library, a change in order of operations, etc. It is generally fruitless to try to match earlier FP results to the last bit. Obviously if the results are significantly different, and your algorithm is stable, there may be something else at work. Any vectorization can change FP results to some degree.

0 Kudos
Reply