IA64 vx x86-64 long double precision

squeen · **Posted:** Thu Jan 14, 2010 7:38 am

I have done some digging but have found only contradictory answers.
Does anyone here know for sure if the long double on x86-64 floating point precision is the full 128bit to some kind of x86 80-bit garbage?

I've only seen that the Itaniums (IA64) are true 128bit.
I assume IRIX was also true 128bit.

Thanks.

zmttoxics · **Joined:** Mon Aug 31, 2009 9:11 am **Posts:** 570

There should be something like "limits.h" which should be system dependant and should have the correct size in it. I think x86_64 supports the full long double, but it also depends on the compiler / os.

zmttoxics · **Joined:** Mon Aug 31, 2009 9:11 am **Posts:** 570

After a quick search I found this... http://gcc.gnu.org/ml/gcc-help/2006-10/msg00138.html

Quote:

IBM AIX on PowerPC and SGI IRIX MIPS also have 128-bit floating-point,
but both use a doubled-double format, which fails to extend the
exponent range, offers a 106-bit significand (instead of a 113-bit
one), and which has serious arithmetic anomalies arising from the fact
that the upper and lower members of the pair do not have their
exponents linked by a constant difference.

jan-jaap · **Posted:** Thu Jan 14, 2010 8:15 am

The "80 bit x86 garbage" can usually be controlled with a platform dependent function to control FP precision and rounding mode etc. It only affects x87 math, not any of the SSE units used mostly these days.

On IRIX:

man(3) math wrote:

Long Double Arithmetic
Long double arithmetic is supported by the compiler. The representation used is not IEEE compliant; long doubles are represented on this system as the sum or difference of two doubles, normalized so that the smaller double is <= .5 ULP of the larger. This is equivalent to a 107 bit mantissa with an 11 bit biased
exponent (bias = 1023), and 1 sign bit. In terms of decimal precision, this is approximately 34 decimal digits.

[...]

Long double arithmetic operations are done in software by MIPSpro compilers; results of these operations may vary slightly from release to release due to improvements in the algorithms which implement them.

(emphasis mine)

MIPS3 and MIPS4 CPUs have 32 double precision FP registers, but none have 128bit registers. Older MIPS CPUs have 32bit FP registers, but the FP can be controlled to pair them into 16 * double precision registers. Refer to man(5) abi for more details.

squeen · **Posted:** Fri Jan 15, 2010 4:52 am

Looks like SGI/IRIX did not implement true 64 bit math in hardware! What a disappointment.

Also, I have seen on some sites info that SSE supports 64-bit math operations, but there is still some doubt in my mind how the 128-bit ops are handled.

A colleague just wrote a small program to test some of the math on an machine architecture. Here is the program and results for two "64-bit" machines. Our Onyx 350 and a Xeon based Intel (x86-64) running CentOS 5.

In particular, the element I care most about is the eps= because that tells me the number of significant digits carried through by our calculations. On IRIX (where I know from experience quad precision runs slow), you get 32 significant digits which matches 128-bit calculations. On the x86-64 arch, you get only 19 significant digits which is consistent with only 80-bit calculations. What a crock 'o poop!

IRIX (Onyx 350 R16K)
compiled with: cc -64 machar.c -o machar -lm

Code:

---- ---- Machine Architecture: with double---- ---- 
 ibeta=                      2 : radix of floating point representation
    it=                     53 : number of base ibeta digits in significand
  irnd=                      1 : 0=floating point addition chops  1=rounds
  ngrd=                      0 : number of guard digits for multiplication
machep=                    -52 : largest negative integer such that 1+ibeta^machep != 1
 negep=                    -56 : largest negative integer such that 1-ibeta^machep != 1
  iexp=                     11 : number of bits reserved for exponent
minexp=                  -1022 : largest magnitude negative int st ibeta^minexp is +
maxexp=                   1026 : largest + int exponent for a finite floating point number
   eps= 2.2204460492503131e-16 : smallest + number st 1+eps != 1
epsneg= 1.3877787807814457e-17 : smallest + number st 1-eps != 1
  xmin=2.2250738585072014e-308 : smallest non-vanishing floating point power of ibeta
  xmax=1.7976931348623155e+308 : largest finite floating point number
---- ---- Machine Architecture: with long double---- ----
 ibeta=                      2 : radix of floating point representation
    it=                    107 : number of base ibeta digits in significand
  irnd=                      1 : 0=floating point addition chops  1=rounds
  ngrd=                      0 : number of guard digits for multiplication
machep=                   -106 : largest negative integer such that 1+ibeta^machep != 1
 negep=                   -110 : largest negative integer such that 1-ibeta^machep != 1
  iexp=                     11 : number of bits reserved for exponent
minexp=                  -1022 : largest magnitude negative int st ibeta^minexp is +
maxexp=                   1026 : largest + int exponent for a finite floating point number
   eps= 1.2325951644078309e-32 : smallest + number st 1+eps != 1
epsneg= 7.7037197775489434e-34 : smallest + number st 1-eps != 1
  xmin=2.2250738585072014e-308 : smallest non-vanishing floating point power of ibeta
  xmax=1.7976931348623158e+308 : largest finite floating point number

Intel(R) Xeon(R) CPU X5482 @ 3.20GHz
compiled with: gcc -m64 -m128bit-long-double machar.c -o machar -lm

Code:

---- ---- Machine Architecture: with double---- ---- 
 ibeta=                      2 : radix of floating point representation
    it=                     53 : number of base ibeta digits in significand
  irnd=                      1 : 0=floating point addition chops  1=rounds
  ngrd=                      0 : number of guard digits for multiplication
machep=                    -52 : largest negative integer such that 1+ibeta^machep != 1
 negep=                    -56 : largest negative integer such that 1-ibeta^machep != 1
  iexp=                     12 : number of bits reserved for exponent
minexp=                  -1074 : largest magnitude negative int st ibeta^minexp is +
maxexp=                   3021 : largest + int exponent for a finite floating point number
   eps= 2.2204460492503131e-16 : smallest + number st 1+eps != 1
epsneg= 1.3877787807814457e-17 : smallest + number st 1-eps != 1
  xmin=4.9406564584124654e-324 : smallest non-vanishing floating point power of ibeta
  xmax=1.7976931348623155e+308 : largest finite floating point number
---- ---- Machine Architecture: with long double---- ----
 ibeta=                      2 : radix of floating point representation
    it=                     64 : number of base ibeta digits in significand
  irnd=                      1 : 0=floating point addition chops  1=rounds
  ngrd=                      0 : number of guard digits for multiplication
machep=                    -63 : largest negative integer such that 1+ibeta^machep != 1
 negep=                    -67 : largest negative integer such that 1-ibeta^machep != 1
  iexp=                     16 : number of bits reserved for exponent
minexp=                 -16445 : largest magnitude negative int st ibeta^minexp is +
maxexp=                  49090 : largest + int exponent for a finite floating point number
   eps= 1.0842021724855044e-19 : smallest + number st 1+eps != 1
epsneg= 6.7762635780344027e-21 : smallest + number st 1-eps != 1
  xmin=3.6451995318824746e-4951 : smallest non-vanishing floating point power of ibeta
  xmax=1.1897314953572318e+4932 : largest finite floating point number

We have two SGI Itanium (Altix) systems here. I'll try to get them up and running to test their math as well.

(I also tried OS X but it was missing finitel() from the math lib and just hung after I removed that section of code. OS X continues to tease, but ultimately fails to deliver real Unix performance.)

My tentative conclusion is that x86-64 is a fake!

squeen · **Posted:** Fri Jan 15, 2010 6:12 am

Here's a 2005 article that seems to indicate that there is no hardware quad support yet, but talks about the SSE2 instruction set being 128-bit wide and capable of 2 simultaneous double precision operations. It also talks about the double-double software quad solution and notes that it is at least 10x slower than just (hardware) double operations. That is consistent with what I saw on IRIX64.

http://www.google.com/url?sa=t&source=web&ct=res&cd=74&ved=0CBAQFjADOEY&url=http%3A%2F%2Fperso.ens-lyon.fr%2Fgilles.villard%2FBIBLIOGRAPHIE%2FPDF%2Fphys06.pdf&rct=j&q=Linux+quad+precision+x86-64&ei=u2ZQS42bM5X-M7_T5ZcJ&usg=AFQjCNGo4C_lBd2wHZXOWHB-N8NTVIsJOA

I am confused about where the disconnect is occuring. I sounds like the 80-bit x87 FPU coprocessor stuff has been replaced by a 128-bit SSE extension, but that it is somehow not usable for fully compliant quad math precision. Where is the disconnect? Which part of the pipeline is unable to handle it? If it was just a compiler issue, you'd think someone (Intel) would have addressed it as a selling point.

Ugh!

jan-jaap · **Posted:** Fri Jan 15, 2010 6:41 am

squeen wrote:

My tentative conclusion is that x86-64 is a fake!

-m128bit-long-double only affects alignment, not precision. But: Notice that neither of these options enable any extra precision over the x87 standard of 80 bits for a long double.

Disappointing.

nekonoko · **Posted:** Fri Jan 15, 2010 7:43 am

squeen wrote:

(I also tried OS X but it was missing finitel() from the math lib and just hung after I removed that section of code. OS X continues to tease, but ultimately fails to deliver real Unix performance.)

I tried it on FreeBSD but got the following:

Code:

$ gcc -m64 -m128bit-long-double machar.c -o machar -lm
/var/tmp//ccXeVNjh.o(.text+0x1412): In function `Lmachar':
: undefined reference to `finitel'
/var/tmp//ccXeVNjh.o(.text+0x14cd): In function `Lmachar':
: undefined reference to `finitel'

squeen · **Posted:** Fri Jan 15, 2010 7:51 am

nekonoko wrote:

I tried it on FreeBSD but got the following:

Code:

$ gcc -m64 -m128bit-long-double machar.c -o machar -lm
/var/tmp//ccXeVNjh.o(.text+0x1412): In function `Lmachar':
: undefined reference to `finitel'
/var/tmp//ccXeVNjh.o(.text+0x14cd): In function `Lmachar':
: undefined reference to `finitel'

Seems like OS X inherited the issue from BSD.

The weird part was when I comment out the tests at the bottom of the code that call finitel (or turned it into just the double precision finite()) the app still hung.

I think I'll make a simpler app that just tests the EPS precision.

EDIT: My current theory is that it is neither a hardware register (i.e. Nehalem, SSE2) issue or a compiler issue, but maybe an instruction set issue, i.e. x86-64 has no instruction to do quad math.

Another lingering peculiarity...if the x86-64 Linux GCC options are 128-bit aligned, -mfpmath=sse so that we are suppose to be doing "64-bit" math and not the x87 "80-bit extended precision" math, where do the extra 3 significant digits come from in going from double to long double?

Also, why is this issue in general ignored (or at least obscured) on the web? I would at least the GCC developers to be talking about it.

zmttoxics · **Joined:** Mon Aug 31, 2009 9:11 am **Posts:** 570

Let me install sun studio on an x4100 with solaris 10 and a blade2500 with the same solaris 10 rev and I will run the test. Two systems with different archs but same compiler / os.

zmttoxics · **Joined:** Mon Aug 31, 2009 9:11 am **Posts:** 570

Actually, between both sparc and x86 with cc and gcc I run into almost the same problem as neko, and its almost the same problem between compilers. (Solaris 10 u8, SStudio12, gcc 3.4.3).

Code:

SPARC gcc:

-bash-3.00#  gcc -m64 -m128bit-long-double machar.c -o machar -lm
cc1: error: invalid option `128bit-long-double'
-bash-3.00#  gcc -m64  machar.c -o machar -lm
Undefined                       first referenced
 symbol                             in file
finitel                             /var/tmp//ccSos1ez.o
ld: fatal: Symbol referencing errors. No output written to machar
collect2: ld returned 1 exit status
-bash-3.00#

Code:

SPARC cc:

-bash-3.00# cc -64 machar.c -o machar -lm
cc: Warning: Option -64 passed to ld, if ld is invoked, ignored otherwise
"machar.c", line 106: warning: argument #2 is incompatible with prototype:
        prototype: pointer to function(int) returning void : "/usr/include/iso/signal_iso.h", line 48
        argument : pointer to void
"machar.c", line 168: warning: argument #2 is incompatible with prototype:
        prototype: pointer to function(int) returning void : "/usr/include/iso/signal_iso.h", line 48
        argument : pointer to void
"machar.c", line 417: warning: implicit function declaration: finite
"machar.c", line 648: warning: implicit function declaration: finitel
ld: fatal: file /opt/sunstudio12.1/prod/lib/crti.o: wrong ELF class: ELFCLASS32
ld: fatal: File processing errors. No output written to machar

-bash-3.00# file /opt/sunstudio12.1/prod/lib/crti.o  
/opt/sunstudio12.1/prod/lib/crti.o:     ELF 32-bit MSB relocatable SPARC Version 1
-bash-3.00#

Code:

x86_64 gcc:

bash-3.00#  gcc -m64 -m128bit-long-double machar.c -o machar -lm
Undefined         first referenced
 symbol               in file
finitel                             /var/tmp//ccQ07rek.o
ld: fatal: Symbol referencing errors. No output written to machar
collect2: ld returned 1 exit status
bash-3.00#

Code:

x86_64 cc:

bash-3.00#  cc -64 machar.c -o machar -lm
cc: Warning: Option -64 passed to ld, if ld is invoked, ignored otherwise
"machar.c", line 106: warning: argument #2 is incompatible with prototype:
   prototype: pointer to function(int) returning void : "/usr/include/iso/signal_iso.h", line 48
   argument : pointer to void
"machar.c", line 168: warning: argument #2 is incompatible with prototype:
   prototype: pointer to function(int) returning void : "/usr/include/iso/signal_iso.h", line 48
   argument : pointer to void
"machar.c", line 417: warning: implicit function declaration: finite
"machar.c", line 648: warning: implicit function declaration: finitel
ld: fatal: file /opt/sunstudio12.1/prod/lib/crti.o: wrong ELF class: ELFCLASS32
ld: fatal: File processing errors. No output written to machar
bash-3.00#

I dont have time to debug anything today, but if you can fix the code or provide proper arguments for use on solaris, I would be happy to try again.

DaSeitz · **Posted:** Fri Jan 15, 2010 10:18 am

HPUX on Itanium seems to be the only platform supporting 128 bit. Does HPUX on PArisc support it? A whole new perspective to look on architectures.

mattst88 · **Posted:** Fri Jan 15, 2010 1:37 pm

SSE uses 128-bit registers, but doesn't operate on 128-bit floating point numbers. Do a little bit of research. Look up SIMD for instance.

I also think if you need 128-bits of precision, you're probably doing something wrong.

Required Wikipedia reading list:

Sorry. Just way too many uninformed comments in this thread.

mattst88 · **Posted:** Fri Jan 15, 2010 1:52 pm

To respond to your question, it appears that IA64 does not support 128-bit quad precision. At least not in hardware.

x86-64 supports floating point via the x87 FPU and SSE. SSE operates on 32-bit and 64-bit floating point values only. The FPU supports these and also an extended 80-bit format. No 128-bit quad precision on x86-64 either. At least not in hardware.

And as you say, IRIX supports 128-bit quad precision only in software.

128-bit precision isn't needed too often.

sybrfreq · **Posted:** Fri Jan 15, 2010 2:20 pm

mattst88 wrote:

I also think if you need 128-bits of precision, you're probably doing something wrong.

Squeen is a rocket scientist or somesuch, and I'm fairly sure there is a good reason for needing all that precision. Progress of mankind and all that jazz.

Anyway this thread wasn't about the why but rather the why not.

Nekochan Net

Forum rules

IA64 vx x86-64 long double precision

Who is online