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??
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Miles Bader <miles at gnu dot org>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, libc-help at sourceware dot org
- Date: Wed, 2 May 2012 16:45:38 -0400
- Subject: Re: Subject: single-precision "expf" super slow on x86-64??
- References: <87aa1vjfol.fsf@catnip.gol.com><CALoOobNgpMvgHR6-5Gwa48L7wRsjZ_eTD6w1C75yEAAqfyw8gA@mail.gmail.com><CADCnXoadj1h2EG46DxX7kdoVYpLZ5DmBW9+Qp=a94Zg9E4uwng@mail.gmail.com><CALoOobO=sNHzEM1NgerMGrWmEb3g-rD4jFN3CATwa00vE=TVJA@mail.gmail.com><CADCnXoZ=Ovp-rxSBu5PxeUuZmS0uYdcbaE6TuujaEEa7pHco3g@mail.gmail.com><CADZpyizabb6MV+122-3pv4yp9=ixbzqDXGVXmpwkRVMASpTYvg@mail.gmail.com><CADCnXoas1zRs=teYoCR+WfhH4JVVMpAJuEfWavu=EnVwgg+1dw@mail.gmail.com>
On Wed, May 2, 2012 at 4:06 PM, Miles Bader <miles@gnu.org> wrote:
> I was hoping that somebody with a deeper understanding of the issues
> could give some feedback as to _why_ this problem occurred in the
> first place, and some idea whether it might still be a problem on
> other platforms. ?Also if "FPU fiddling" really is the reason for the
> slowdown (that's of course just my guess, which is why it would be
> good to hear from someone with more experience), then it looks like
> maybe the _double-precision_ exp function is now doing something
> similar (whereas before only the single-precision code was doing
> it)...!
>
> Anyway, _is_ this the right list to ask this sort of question?
Yes, it *is* the right list to ask this question.
Unfortunately answering your question is difficult and time consuming.
Volunteers want to spend time making the code better :-)
Therefore we rely on *you* to do some due-diligence like testing on trunk.
At the end of the day the problem will come full circle once you
figure out why it's slow and the following pattern will repeat.
Imagine libm performance as a spectrum:
|<--- really fast and inaccurate ...... really slow and accurate --->|
With the current framework a given libm implementation must fall
somewhere in the spectrum.
Say here:
|<--- ......................................X................... --->|
You want:
|<--- ........X................................................. --->|
You complain that exp is slow.
We speed up exp through trickery which includes a loss of accuracy.
Others now complain that exp is inaccurate.
Worse you want:
|<--- ........X................................................. --->|
and your 3rd party library wants:
|<--- .......................................................X.. --->|
within the same executable.
What now?
This is an unsolved problem for the community.
We're always looking for new volunteers :-)
Cheers,
Carlos.