glibc math improvements
brde at optusnet.com.au
Sun Jan 4 12:47:03 UTC 2015
On Sun, 4 Jan 2015, Pedro Giffuni wrote:
>> Il giorno 03/gen/2015, alle ore 23:37, Steve Kargl <sgk at 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.
More information about the freebsd-numerics