Re: glibc very old

[Vincent Lefevre <vincent@vinc17.net>]

On 2012-07-26 03:58:33 +0900, Miles Bader wrote:
> Vincent Lefevre <vincent@vinc17.net> writes:
> >> So... these functions were made almost an order of magnitude slower
> >> in the (overwhelmingly) common case, in order to handle rare and
> >> exceptional cases...?
> >
> > This depends on the processor. You should get a processor that
> > handles rounding-mode change in a better way (the slowdown should
> > not be noticeable when you just run the program, without looking at
> > the exact running time).
> 
> It's about 5 times slower on both phenom2 (AMD) and core2 (Intel)
> cpus.... I dunno if these are unusual.

I can reproduce a 3.4x slowdown with:

#include <stdio.h>
#include <float.h>
#include <math.h>
#include <fenv.h>
#pragma STDC FENV_ACCESS ON

int main (void)
{
  volatile double x = 1.0, y;
  int i;

  for (i = 0; i < 100000000; i++)
    {
      fesetround (FE_TONEAREST);
      y = exp(x);
      fesetround (FE_TONEAREST);
    }
  return y == 0.0;
}

and Debian's glibc and Intel Core 2 Duo. I'll try to have more
information about why the processor doesn't detect that the
rounding mode doesn't change.

But with:

#include <stdio.h>
#include <float.h>
#include <math.h>
#include <fenv.h>
#pragma STDC FENV_ACCESS ON

int main (void)
{
  volatile double x = 1.0, y;
  int i;

  for (i = 0; i < 100000000; i++)
    {
      int r = fegetround();
      if (r != FE_TONEAREST)
        fesetround (FE_TONEAREST);
      y = exp(x);
      if (r != FE_TONEAREST)
        fesetround (r);
    }
  return y == 0.0;
}

I only get a 9% slowdown. I suppose that withing glibc code, it can
be lower. The advantage of this method compared to remembering the
rounding mode in glibc is that it is 100% safe, in case the user or
some library bypasses the C libary to change the rounding mode.

I think that there could be an optimization like that in
fesetround() too.

> Ok, I guess there's no really guaranteed way to make it fast, so
> glibc's method (with arch-specific reimplementations for those cases
> where it proves to be slow) it is reasonable enough ...

Yes, the chosen method could depend on the processor.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)