Re: Subject: single-precision "expf" super slow on x86-64??

[Miles Bader <miles at gnu dot org>]

2012/5/3 Carlos O'Donell <carlos@systemhalted.org>:
> On Sun, Apr 29, 2012 at 10:22 PM, Miles Bader <miles@gnu.org> wrote:
>> That's the 2.13 code; the current master has replaced the above FPU
>> fiddling with some sort of macro... and now the _double_ version of
>> the C code does some FPU fiddling too...
>>
>> Is there a better mailing list to post to? ?I'd be interested some
>> maintainer's viewpoint on this stuff...
>
> Paul is a maintainer, and so am I :-)

Whoops.  Sorry :]

> Could you to try again against glibc trunk and see if the issue is
> still present?
>
> The community has done a lot of work to fix up libm after the 2.15 release.
>
> If you don't have time to test against glibc trunk please file a bug
> in bugzilla and ensure that you mark it with component=math.

Hmm, ok, ... I don't know when I'll have the time to build it though...

It's good there's now a rewritten-in-assembly version of the function
for x86-64, and I suppose there's probably a good chance it solves the
issue for me personally [once I have that version of the library], but
of course doesn't help other platforms.

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?

Thanks,

-Miles

-- 
Cat is power. ?Cat is peace.