Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Intel Community
- Software Development Tools (Compilers, Debuggers, Profilers & Analyzers)
- Intel® C++ Compiler
- Multiple machines, multiple outputs

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

aurora

Beginner

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

03-06-2013
01:39 AM

41 Views

Multiple machines, multiple outputs

Hi,

I'm having different results in floating point operations in my algorithms depending on the machine that is being executed. Same architecture (x64), same binaries, but not same processor. It also occurs with /debug:full, /Qfp-speculation:off, /fp:strict...

NOT using BLAS, LAPACK, any external library or random data. Only floating point instructions.

Is this normal? Is it possible to produce reproducible results?

Thanks in advance!

Intel C++ Compiler 12.1 update 258

Link Copied

15 Replies

TimP

Black Belt

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

03-06-2013
04:26 AM

41 Views

SKost

Valued Contributor II

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

03-06-2013
05:41 AM

41 Views

SKost

Valued Contributor II

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

03-06-2013
05:47 AM

41 Views

aurora

Beginner

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

03-06-2013
06:51 AM

41 Views

Is the result of an iterative method that computes hundred of millions times some instructions. i.e.:

------

t=difx1**d *difx[i+m];*

dd=(c[i+1]-d)/(t-c[i+1]);

d=c[i+1]*dd;

c=t*dd;

-------

All are double operations. On each iteration I compare the error with a thresold (order 10^-3= and I decide whether to continue or not. So it is not easy to show results (too many output data)

In that case, this could be just an inestable algorithm? How can I do it better? Using more precission?

SKost

Valued Contributor II

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

03-06-2013
07:03 AM

41 Views

SKost

Valued Contributor II

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

03-06-2013
07:08 AM

41 Views

jimdempseyatthecove

Black Belt

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

03-06-2013
09:41 AM

41 Views

Computation using irrational numbers mostly produce irrational results. Double precision floating point uses 52 bits for mantissa with and implied 1 (53 bits of precision for fraction). Some fractional numbers cannot be exactly represented using a finite number of bits (some whole cannot either). A good example of this is the binary value of the decimal 0.1, this is 0.1100110011001100... This is an infinite repeating fraction. In DP FP this fraction will be left shifted by 1 bit and binary exponent diminished by 1 (to account for the shift). the 1. is removed as excepting for 0 and denormalized numbers, it will always be 1. this leave a binary fraction of:

[cpp]

1001100110011001100110011001100110011001100110011001100110011001100... (infinite irrational)

0000000001111111111222222222233333333334444444444555 (10's bit counter)

1234567890123456789012345678901234567890123456789012 (1's bit counter)

1001100110011001100110011001100110011001100110011010 (rounded to 52 bits)

00000000000000000000000000000000000000000000000000000110011001100... (+error)

[/cpp]

Depending on how and how often you manipulate these numbers, the error grows. Using longer floating point formats postpone the error from creaping into the results beyond acceptible levels, but will not eliminate it from happening. Programmers can work around these errors if need be but in many cases the error is within an acceptible range and can be ignored.

Even before the days of binary computers, numerical computations had to take into consideration error in values. SIN, COS, LN tables were published to finite number of places.

Jim Dempsey

Bernard

Black Belt

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

03-06-2013
09:37 PM

41 Views

SKost

Valued Contributor II

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

03-07-2013
05:14 AM

41 Views

aurora

Beginner

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

03-08-2013
06:56 AM

41 Views

Hi,

We are testing our algorithms with long double type data in terms of accuracy and times. A priori, we think the problem is solved. Would you say that operations with long double are much heavier in time?

I understand your explanations, but I still dont see why results changes depending on the machine. i.e. Intel Xeon and Core Duo with same binaries.

Thanks

SKost

Valued Contributor II

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

03-08-2013
11:23 AM

41 Views

>>...Would you say that operations with long double are much heavier in time?
Yes.

Bernard

Black Belt

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

03-10-2013
10:59 PM

41 Views

>>>but I still dont see why results changes depending on the machine. i.e. Intel Xeon and Core Duo with same binaries.>>>

Maybe this is due to various microcode and/or hardware implementation of the rounding algorithms.As Tim said there are also programming errors and there is also some possibility of the hardware errors which could manifest themselves as a loss of accurracy.

SKost

Valued Contributor II

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

03-11-2013
05:22 AM

41 Views

Mark_S_Intel1

Employee

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

03-11-2013
11:27 AM

41 Views

The article at http://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compi... may provide some additional insights.

--mark

Bernard

Black Belt

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

03-12-2013
12:00 AM

41 Views

@mark-sabahi

It was a very interesting article.Thanks for link.

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