Date: Thu, 1 Mar 2012 18:48:56 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Peter Wemm <peter@wemm.org> Cc: freebsd-amd64@freebsd.org Subject: Re: Gcc46 and 128 Bit Floating Point Message-ID: <20120301182241.Q3280@besplex.bde.org> In-Reply-To: <CAGE5yCoTN-qMMs3tLew8W7FgUFmT-kkXeuP7MGKKE3oM7eNC3Q@mail.gmail.com> References: <4F3EA37F.9010207@speakeasy.org> <CAGE5yCpvF0-b1iKAVGbya=fUNaYbGyrpj1PHSQxw4BvycNMLDg@mail.gmail.com> <4F3EC0B4.6050107@speakeasy.org> <4F4DA398.6070703@speakeasy.org> <20120229161408.G2514@besplex.bde.org> <4F4DDCE7.9000008@speakeasy.org> <20120229192417.U3167@besplex.bde.org> <CAGE5yCoTN-qMMs3tLew8W7FgUFmT-kkXeuP7MGKKE3oM7eNC3Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-645216518-1330588136=:3280 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 29 Feb 2012, Peter Wemm wrote: > On Wed, Feb 29, 2012 at 12:40 AM, Bruce Evans <brde@optusnet.com.au> wrot= e: >> 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= =2E >>>> ... >>> I have an application that takes 10 days to run on a 4.16GHz Core-i7 >>> 3930K. No output until it finishes. >> >> Look elsewhere :-). =A01000 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. Yes, and 256-bit hardware FP would be even faster. But neither exists. There is no magic, and libgmp is likely already faster than any software FP can be, since it has access to the same wide SSE/AVX registers as=20 software FP, and multi-precision integers are a little easier, and is more developed. I think software FP would only beat software mp if the algorithm really wanted FP and this had to be emulated with multi- precision integers. I don't know if libgmp already does the latter. It would be difficult for an application to fake it efficiently, but an mp library could do much the same as an FP library for it and then integrate it efficiently with the integers. > 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. On sparc64 you can have "hardware" 128-bit FP with nice 64-bit instructions for it, but gcc intentionally doesn't use this by default, because apparently there is no sparc64 hardware that implements it in hardware; thus it has to be emulated in software using essentially the same code as soft-float, but has extra overheads for trapping on every 128-bit instruction. In the FreeBSD implementation, many of the traps are handled in userland. So there is first the trap overhead, then signal handler overhead before getting to soft-float. Handling traps in userland makes the traps easier to debug, but gdb support for sparc64 FP is primitive and gdb support for sparc64 FP signal handlers is worse. > 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. Indeed, the toolchain issues are hard to handle, even if you have gcc-4.6+ set up. Bruce --0-645216518-1330588136=:3280--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120301182241.Q3280>