Prev: negative zeros and dot_product matmul
Next: F2003 Standard question to constructors (type name = generic name)
From: brady_fht on 18 May 2010 13:45 Okay  I have changed the program slightly (Real declarations, added parentheses, and eliminated one variable):  PROGRAM DPStudy IMPLICIT NONE REAL(KIND=KIND(0.D0)) :: FVF REAL(KIND=KIND(0.D0)) :: THR REAL(KIND=KIND(0.D0)) :: Dum1 FVF = 3.3D0 THR = 3.0D0 Dum1 = (FVF * THR) * DSQRT(THR) 1 FORMAT(A, ES28.22) WRITE(*,1) 'Dum1 = ', Dum1 STOP ENDPROGRAM DPStudy  Now I want to focus on only two scenarios:  COMPILER: gfortran m32 O0 main.f90 OUTPUT: Dum1 = 1.7147302994931884256857E+01   COMPILER: gfortran m64 O0 main.f90 OUTPUT: Dum1 = 1.7147302994931880704144E+01  So, neglecting optimization the 32 and 64 bit versions of this program yield a different result. And the program now uses parentheses to force the order of multiplication. Also, here is the binary representation (all 64 bits) of each result (1st line is 32 bit program result, and 2nd line is the 64 bit program result): 0110101110101011100101000110010110101101101001001000110000000010 1010101110101011100101000110010110101101101001001000110000000010 So the only two bits that are different are the two least significant bits. I guess I am just confused as to how this number is being computed differently. Maybe I'm missing something obvious here or maybe somebody is already slapping me in the face with the answer, but I can't wrap my head around it. Thanks!
From: brady_fht on 18 May 2010 13:49 On May 18, 11:41 am, Tobias Burnus <bur...(a)netb.de> wrote: > On 05/18/2010 05:39 PM, brady_fht wrote: > > > I need some help understanding floating point operations. I am seeing > > a small difference in a program when it is compiled for 32 and 64 bit > > machines. Here is the program: > > > Pretty simple. I am using gfortran 4.3.3 on Ubuntu 9.04. The following > > shows the different compiler options I use and the resulting output > > from the above program: > > gfortran m32 O0 main.f90 > > gfortran m64 O0 main.f90 > > By default GCC on x84 (ia32, i686, ...) uses the floatingpoint > coprocessor "x87" (mfpmath=386) while on x8664 (AMD64, Intel64, em64t, > ...) by default SSE is used. While SSE uses proper rounding, the x87 > processor has some excess precision, which is used for intermediate > results. One way to force the rounding is to store the intermediate > result in memory (opposed to the x87 registers); in GCC/gfortran you can > use ffloatstore to force this.* > > When you use O1 (or higher), the compiler plugs in the values of the > variables and calculates the result at compile time (with proper rounding). > > If you want to see what the compiler does, you can use the > fdumptreeall option, which dumps a (simplified, Csyntaxlike) > internal representation. The "original" and "optimized" are probably > most interesting. > > > For what it's worth  similar behavior was observed using the Intel > > Fortran Compiler 11.1 for Windows. > > (Newer) Intel compilers default to SSE. > > * = GCC 4.5 and 4.6 also offer fexcessprecision=, but I think this > option is not yet supported for GCC's Fortran front end. Additionally, > GCC 4.5 and 4.6 have now a compiler compiletime configuration option, > which allows to enable SSE by default (withfpmath=sse). > For details, seehttp://gcc.gnu.org/gcc4.5/changes.html > > * * * > > General remark: Don't look too closely at the last digits in > floatingpoint calculations and do not assume that changing the order > won't change the result. I would also suggest you to read the Goldberg > paper. > > a) Goldberg paper:http://www.google.de/search?q=Goldberg+What+Every+Computer+Scientist+... > > b) Monniaux paper:http://hal.archivesouvertes.fr/hal00128124 > > c) Semantics of Floating Point Math in GCChttp://gcc.gnu.org/wiki/FloatingPointMath > > d) Note on the x87 coprocessor (for GCC)http://gcc.gnu.org/wiki/x87notehttp://gcc.gnu.org/wiki/Math_Optimization_Flags > > e) IEEE 754:2008 "IEEE Standard for FloatingPoint Arithmetic"http://ieeexplore.ieee.org/servlet/opac?punumber=4610933http://www.validlab.com/754R/drafts/archive/20061004.pdf(last > publicly available draft I found) > > Tobias Thanks Tobias! A lot of good info here that I will dive into. The " ffloatstore" flag did the trick and your explanation makes sense. Just FYI  I couldn't get the Intel compiler to give the same behavior using the program I posted but I have a much larger program that was exhibiting similar behavior and turning optimization on eliminated the differences in results. I will have to look at it closer.
From: Tim Prince on 18 May 2010 14:04 On 5/18/2010 10:49 AM, brady_fht wrote: > On May 18, 11:41 am, Tobias Burnus<bur...(a)netb.de> wrote: > > Just FYI  I couldn't get the Intel compiler to give the same behavior > using the program I posted but I have a much larger program that was > exhibiting similar behavior and turning optimization on eliminated the > differences in results. I will have to look at it closer. When you use ifort, by default, the x87 precision mode is set to 53bit, so you won't see as many differences between SSE2 and x87 double precision as you would with gfortran. x87 single precision x87 expressions are still promoted to double implicitly. You may also be interested in the list of options which have to be set to make ifort comply with standards: http://software.intel.com/enus/forums/showthread.php?t=74331&o=d&s=lr  Tim Prince
From: glen herrmannsfeldt on 18 May 2010 14:19 brady_fht <brady.m.adams(a)gmail.com> wrote: (snip) > Thanks Tobias! A lot of good info here that I will dive into. The " > ffloatstore" flag did the trick and your explanation makes sense. > Just FYI  I couldn't get the Intel compiler to give the same behavior > using the program I posted but I have a much larger program that was > exhibiting similar behavior and turning optimization on eliminated the > differences in results. I will have to look at it closer. Note, though, that if your program is sensitive to the difference in results in the last bit of a product, then you should fix the program. If you are trying to compare different versions of a program, then the comparison should be such that LSB bit errors are tolerated.  glen
From: robin on 18 May 2010 23:18 "brady_fht" <brady.m.adams(a)gmail.com> wrote in message news:ad8f66634c104c029aaef8430808cfe3(a)a16g2000vbr.googlegroups.com...  Okay  I have changed the program slightly (Real declarations, added  parentheses, and eliminated one variable): But you haven't changed DSQRT to SQRT. Also, you didn't read in the variables. Have you tried examining the bits of 3.3? in both cases?    PROGRAM DPStudy  IMPLICIT NONE  REAL(KIND=KIND(0.D0)) :: FVF  REAL(KIND=KIND(0.D0)) :: THR  REAL(KIND=KIND(0.D0)) :: Dum1   FVF = 3.3D0  THR = 3.0D0   Dum1 = (FVF * THR) * DSQRT(THR)   1 FORMAT(A, ES28.22)  WRITE(*,1) 'Dum1 = ', Dum1  STOP  ENDPROGRAM DPStudy     Now I want to focus on only two scenarios:     COMPILER:  gfortran m32 O0 main.f90  OUTPUT:  Dum1 = 1.7147302994931884256857E+01       COMPILER:  gfortran m64 O0 main.f90  OUTPUT:  Dum1 = 1.7147302994931880704144E+01      So, neglecting optimization the 32 and 64 bit versions of this program  yield a different result. And the program now uses parentheses to  force the order of multiplication.   Also, here is the binary representation (all 64 bits) of each result  (1st line is 32 bit program result, and 2nd line is the 64 bit program  result):   0110101110101011100101000110010110101101101001001000110000000010  1010101110101011100101000110010110101101101001001000110000000010   So the only two bits that are different are the two least significant  bits.   I guess I am just confused as to how this number is being computed  differently. Maybe I'm missing something obvious here or maybe  somebody is already slapping me in the face with the answer, but I  can't wrap my head around it.   Thanks!
First

Prev

Next

Last
Pages: 1 2 3 Prev: negative zeros and dot_product matmul Next: F2003 Standard question to constructors (type name = generic name) 