Gcc46 and 128 Bit Floating Point

[Peter Wemm]

On Wed, Feb 29, 2012 at 12:40 AM, Bruce Evans <brde at optusnet.com.au> wrote:
> On Wed, 29 Feb 2012, Thomas D. Dean wrote:
>> On 02/28/12 22:03, Bruce Evans wrote:
>>> But why would you want it? It is essentially unusable on sparc64,
>>> since it is several thousand times slower than 80-bit floating point
>>> on i386. At equal CPU clock speeds, it is only about 1000 times slower.
>>> ...
>> I have an application that takes 10 days to run on a 4.16GHz Core-i7
>> 3930K. No output until it finishes.
>
> Look elsewhere :-).  1000 times slower than that would be bad :-).

See below:

>> The application uses libgmp, but, about 1/2 to 2/3 of the work will fit in
>> a 128-bit float.

This is what he's getting at.  If he could get access to 128 bit fp,
he could move between 1/2 and 2/3 of the work into hardware operations
and bypass a large chunk of GMP work which would be many many times
slower than 128 bit hardware FP.

ports gcc with -march/-mtune set correctly and quadmath is his only
option.  If he's got gcc-4.6 generating code for generic amd64
instructions it won't use that stuff and will soft-float it.  Those
switch settings might be the difference between the earlier code
reports that didn't show use of the instructions vs later ones that
did.

libm and libc can't grow support for __float128 with our existing
compiler.  We could write some in assembler but that doesn't do
anything for libc like printf.  he also said "no output for 10 days"
so I'm guessing printf isn't an issue.

Keeping it out of band with gcc-4.6+ / libquadmath and some impedance
matching with libgmp is his only practical option.  Later snapshots of
gcc may even be required if its missing things he needs.

-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell