Date: Wed, 5 Mar 2008 22:38:07 -0500 From: David Schultz <das@FreeBSD.ORG> To: Colin Percival <cperciva@FreeBSD.ORG> Cc: cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, Bruce Evans <bde@FreeBSD.ORG>, Bruce Evans <brde@optusnet.com.au>, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/include _types.h Message-ID: <20080306033807.GB47280@zim.MIT.EDU> In-Reply-To: <47CF5AE8.2090101@freebsd.org> References: <200803051121.m25BLE03035426@repoman.freebsd.org> <47CE8396.6020803@freebsd.org> <20080306095645.V7605@delplex.bde.org> <47CF5AE8.2090101@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 05, 2008, Colin Percival wrote: > Bruce Evans wrote: > > On Wed, 5 Mar 2008, Colin Percival wrote: > >> Bruce Evans wrote: > >>> Change float_t and double_t to long double on i386. > >> > >> Doesn't this have a rather severe performance impact on any code which > >> uses double_t? > > > > No. As mentioned in the commit message, this has no performance effect > > except in cases where it avoids compiler bugs. [...] if you use long double > > for memory variables then you get a severe performance impact and some > > space loss for the load instruction, since loading long doubles is > > much slower than loading doubles (about 4 times slower on Athlons). > > Either I'm misunderstanding something, or you seem to be disagreeing with > yourself here... if I have the following code > > double_t foo, bar, foobar; > foobar = foo + bar; > > then prior to this change the processor loads and stores doubles, while > after this change the processor loads and stores long doubles, with the > associated performance penalty. If gcc actually implemented IEEE 754R / C99 / LIA1 correctly, then when compiling something like 'double x = y' would require it to store the value to memory and then reload it to force it to 53-bit precision. The whole point of double_t is to allow the programmer to ask for a variable that is "at least double precision", so that the compiler isn't forced to clip everything to double precision if it's inefficient to do so. However, gcc doesn't compile the above expression correctly, and FreeBSD works around the problem by setting the default rounding mode to 53 bits, which is why it's pointless to increase the size of double_t.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080306033807.GB47280>