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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 Percival
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47CF5AE8.2090101>