Date: Wed, 05 Mar 2008 18:46:00 -0800 From: Colin Percival <cperciva@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans <bde@FreeBSD.org>, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/include _types.h Message-ID: <47CF5AE8.2090101@freebsd.org> In-Reply-To: <20080306095645.V7605@delplex.bde.org> References: <200803051121.m25BLE03035426@repoman.freebsd.org> <47CE8396.6020803@freebsd.org> <20080306095645.V7605@delplex.bde.org>
index | next in thread | previous in thread | raw e-mail
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. Colin Percivalhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47CF5AE8.2090101>