Date: Sun, 4 Jan 2015 23:46:46 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Pedro Giffuni <pfg@freebsd.org> Cc: freebsd-numerics@freebsd.org, Steve Kargl <sgk@troutmask.apl.washington.edu> Subject: Re: glibc math improvements Message-ID: <20150104233859.P1781@besplex.bde.org> In-Reply-To: <CE6A1215-FD5E-4535-9CF7-081649C06898@freebsd.org> References: <884D1A4A-76B7-4E7B-939A-6FD7D6D6D18D@freebsd.org> <20150104043745.GA79370@troutmask.apl.washington.edu> <CE6A1215-FD5E-4535-9CF7-081649C06898@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 4 Jan 2015, Pedro Giffuni wrote: > >> Il giorno 03/gen/2015, alle ore 23:37, Steve Kargl <sgk@troutmask.apl.washington.edu> ha scritto: >> >> On Sat, Jan 03, 2015 at 10:00:58PM -0500, Pedro Giffuni wrote: >>> >>> This blog post was covered by Phoronix: >>> http://developerblog.redhat.com/2015/01/02/improving-math-performance-in-glibc/ <http://developerblog.redhat.com/2015/01/02/improving-math-performance-in-glibc/>; >>> >>> Not sure any of that stuff is applicable to our implementation but it looks like an interesting link to share nevertheless. >>> >> >> AFAICT, it is not applicable. The improvements are in >> a 768-bit multi-precision computation of pow() to get an >> accurate answer. The article mentions that the technique >> may be applied to exp() and log(), but the table-driven >> methods that Bruce, David, and I used for logl, expl, and >> exp2l are quite accurate (somewhere around ulp < 0.55 or so). > > OK, I see, apparently the improvements only apply for worst-case > scenarios but we never hit them. 768 bits is a lot. Expect a slowness factor of a few hundred. We use at most 64 extra bits in exp() and log() and work hard to make the slowness factor closer to 1 than 2. pow() has more worst cases than exp() and log(), but 768 bits for it seems excessive. Maybe that is needed for perfect rounding. sin(x) needs only about 64 bits for for perfect rounding after its arg is reduced, but the arg reduction step requires almost 20000 bits in the worst case. We don't attempt to do perfect rounding. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150104233859.P1781>