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

[Miles Bader <miles at gnu dot org>]

2012/4/30 Paul Pluzhnikov <ppluzhnikov@google.com>:
>>> This has very likely been fixed by
>>> http://sources.redhat.com/git/?p=glibc.git;a=commitdiff;h=39adf059fccb7333f61a488d73172b0d8aa2d580
>>
>> Was there previously an optimized version of "exp", but not "expf"
>> (since "exp" is already much faster)?
>
> You can trivially answer that yourself, e.g.

Hmm, thanks for the tip...

The answer doesn't seem so clear tho...

In 2.13, these seem to be the files used:

single-precision:
  sysdeps/ieee754/flt-32/e_expf.c (wrapper)
  sysdeps/ieee754/flt-32/w_expf.c (real function)

double-precision:
  sysdeps/ieee754/dbl-64/w_exp.c (wrapper)
  sysdeps/ieee754/dbl-64/e_exp.c (real function)

The wrappers seem more or less identical for both precisions, so I
guess they can be ignored.

The real functions are both written in C, but are quite different, and
come from different sources.

The single-precision version seems a little bizarre to me, and does
some things that look kinda dubious, e.g. fiddling with the FPU state
(sysdeps/ieee754/flt-32/e_expf.c:89):

      fenv_t oldenv;
      feholdexcept (&oldenv);
#ifdef FE_TONEAREST
      fesetround (FE_TONEAREST);
#endif

[my vague impression is that fiddling with the FPU settings can be very slow...]

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...

Thanks,

-miles

-- 
Cat is power. ?Cat is peace.