Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

Consistency with long double

velvia
Beginner
328 Views

Hi,

I am working on a C++ program which is heavy on number crunching. After an update of the program that has nothing to do with floating points (I have added non floating point members to some classes), I realized that there was a slight change in the floating point results of the program. The difference is very small (a small drift starting from 1ulp), but it is there.

I've tracked the difference in between the 2 versions of the program, until I found the culprit : a routine that was using the type "long double". When changed to "double", the difference went away.

Is there any reason why some "external change" to a code might affect "long double" computation and not computation with "double" ?

Best regards,

Francois

0 Kudos
6 Replies
Kittur_G_Intel
Employee
328 Views

Hi,
You can refer to a good read on consistency of floating point results which goes over some of the compiler switches you can use to set appropriate granularity for floating point semantics in your application depending on the context of your application at:

https://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compiler/

BTW, the error may result due to rounding intermediate results or due to precision mapped to double/long double (double precision/extended double precision) etc as well. Basically, if you have an option of using more than one data type for a variable, use of double comes first instead of long double from efficiency of the floating point optimization is concerned as well.

_Kittur

0 Kudos
velvia
Beginner
328 Views

Hi Kittur,

I have tested both versions of the program with:

-fp-model source -no-prec-div -no-prec-sqrt

and the problem is still there. It seems that the use of "long double" makes the program "unstable" which does not happen when using double. It turns out that using "long double" in the first place is useless and was a mistake of the programmer, but I would like to understand what's going on here.

0 Kudos
TimP
Honored Contributor III
328 Views

With so many possibilities, perhaps you could define the issue better.  Are you running in 32 bit mode with some or all functions built with " ia32" architecture? Are multiple compilers involved? Linux, Mac? 32 or 64 bit Os? Are the quoted options the full group used for main()?

0 Kudos
Kittur_G_Intel
Employee
328 Views

@velvia:  Tim makes a good point in that you probably need to elaborate the issue in terms of the build and target platform details. Also, which version of the compiler you're using? Invoking %icc -V   outputs the version and build info.   Also, try using "-fp-model precise -fp-model source"  i as  the option instead of just fp-model source.  

Other than that,  if you can reproduce the issue on a small reproducer then compile that test case with -P  option which will generate the pre-processed file (.i suffix) which you can attach to this issue?  I can then investigate further accordingly, appreciate much.

_Kittur

 

0 Kudos
velvia
Beginner
328 Views

Hi Kittur,

This problem is found with the Intel compiler, gcc and clang. The Intel compiler I was using is 15.x.x, on Linux on x86_64.

I have tried with "-fp-model precise -fp-model source" but it does not make a difference.

Unfortunately, it is difficult to extract the code and make a small reproducer. I'll guess I need to work hard on that if I want to understand what's going on.

0 Kudos
Kittur_G_Intel
Employee
328 Views

@velvia:  If that's the case then it's hard to decipher what's going on as I thought it could be related to floating point optimizations per-se. Since it's also happenning with gcc and clang there's something going on in the code. Try reduced optimizations and see if it helps to narrow down. Again, yes it'll be great if you can attach a reproducer for further investigation else it's not easy to do find out, thanks.

_Kittur

0 Kudos
Reply