This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Subject: single-precision "expf" super slow on x86-64??
2012/5/3 Carlos O'Donell <carlos@systemhalted.org>:
> You complain that exp is slow.
Hmm, well, not exactly -- I complained that:
* expf (single-precision) is slow, while exp (double-precision) is
much faster (about six times faster)
* *but* there doesn't seem to be much accuracy difference: replacing
"expf(x)" with "(float)exp((double)x)" [1] returns the _same answer_
99.97% of the time[2], and those times it _doesn't_ return the same
answer, the answer is within +/- 1 single-precision ULP.
e.g. from my test program, here's a representative difference:
(float)exp(0x1.ace768p-3) = 0x1.3ba3e8p+0 [3f9dd1f4]
extf(0x1.ace768p-3) == 0x1.3ba3eap+0 [3f9dd1f5]
delta = -0x1p-23 [b4000000]
[1] Not entirely trivial, as gcc sometimes does the inverse
substitution, silently replacing "(float)exp((double)x)" with
"expf(x)" !!
[2] 99.97% is not a guess; in my test prog, it returned a different
answer (but always within +/- 1 ULP) 297 times out of 1,000,000...
> We speed up exp through trickery which includes a loss of accuracy.
I understand that there's often a tradeoff between speed and accuracy,
it's not clear that it's really relevant here, since expf was much
slower, but not achieving any better accuracy (indeed, it was probably
worse).
I have no doubt that the new assembly version is faster, for x86-64 at
least, (and I will test it when I get the time), but there really does
seem to be something funny going on here. I'd really like to
understand _why_ this problem is happening (I've given my guess, but
it's just that). I'm looking for some insight; while testing the
newer library to see if the problem is "solved" is a good thing
practically, it's not really going to yield much in the way of
explanation...
Thanks,
-Miles
--
Cat is power. ?Cat is peace.