Showing results for

- Intel Community
- Software
- Software Archive
- Numeric difference by libimf.a with gcc compiler

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Dahe_C_

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-22-2016
04:41 PM

114 Views

Numeric difference by libimf.a with gcc compiler

I am using 5.3 gcc with libimf.a (have but can't use icc due to other reasons) and find that the exp() function returns different values for certain numbers when the same build is run on Sandy Bridge and Haswell running CentOS6. The library comes with pxtudioxe both 2016 and 2017. For example,

#include <math.h>

#include <stdio.h>

int

main()

{

const double v = 3.3990833195703927;

printf("exp(v) = %.20e\n", exp(v));

}

produces

2.99366451289085517828e+01

2.99366451289085482301e+01

on the two architectures. The code is compiled with "gcc main.cc .../libimf.a .../libirc.a". Is there a way to use the library with gcc such that it is architecture-independent?

Dahe

Link Copied

10 Replies

SergeyKostrov

Valued Contributor II

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-08-2017
03:56 PM

114 Views

TimP

Black Belt

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-09-2017
04:54 AM

114 Views

But big cpu math libraries aren't topical on this forum.

TimP

Black Belt

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-09-2017
05:02 AM

114 Views

jimdempseyatthecove

Black Belt

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-09-2017
05:42 AM

114 Views

Sergey,

I think you intended to print in hexadecimal format

printf( "exp(v) = %.20e, %0llX\n", r, r ); // both double and Hex (64 bits)

I also agree with your statement that the difference may be attributable to the conversion of the double to the text string printed. Should the Hex formats show the same number, then this would indicate that the issue involves the conversion of the double to the text string.

Jim Dempsey

McCalpinJohn

Black Belt

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-09-2017
11:29 AM

114 Views

Using the utility at http://www.binaryconvert.com/convert_double.html, it is clear that these two values differ by one least significant bit.

This is not at all surprising, since Sandy Bridge must use separate Add and Multiply operations, while Haswell can use the more accurate FMA instruction.

The GNU C library does not aim to provide exactly the same results on all platforms. The goals of the project and error estimates for many of the available functions are at https://www.gnu.org/software/libc/manual/html_node/Errors-in-Math-Functions.html. ; On that page, the first goal of the project is to "provide a result that is within a few ULP of the mathematically correct value of the function". A difference of one ULP across platforms is consistent with this definition.

If the goal is to get exactly the same bits on all platforms, it may be possible to trick the library into using the Sandy Bridge code path on the Haswell platform. This will eliminate the FMA instructions and *might* provide identical results. I don't know how to do this with the GNU compilers and libraries, but there is probably enough information at https://lwn.net/Articles/691932/ to get started on understanding how this works and how it might be controlled.

SergeyKostrov

Valued Contributor II

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-09-2017
02:07 PM

114 Views

SergeyKostrov

Valued Contributor II

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-09-2017
02:18 PM

114 Views

TimP

Black Belt

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-09-2017
02:19 PM

114 Views

SergeyKostrov

Valued Contributor II

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-09-2017
02:22 PM

114 Views

McCalpinJohn

Black Belt

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-10-2017
08:35 AM

114 Views

The AVX2 math functions that are able to use FMA operations should probably be assumed to be more accurate than the corresponding implementations that require rounding between the multiply and add operations. (There will always be point-wise counter-examples, but unless the implementation is bad, any reasonable norm on a distribution of results should show the FMA-based results to be more accurate on "average".)

Unfortunately, emulating the increased accuracy of the Fused Multiply-Add is quite expensive on machines that only support separate operations, so if you want bit-wise reproducibility, you almost certainly need to try to reproduce the non-FMA results.

Bitwise reproducibility will also require identical ordering of operations, which for some algorithms means that all results must be computed with the same vector length on all platforms. A vector length of 1 is a convenient value, but a vector length of 2 doubles is probably supported by all of the platforms of interest.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page

For more complete information about compiler optimizations, see our Optimization Notice.