Re: glibc very old

[Miles Bader <miles@gnu.org>]

Vincent Lefevre <vincent@vinc17.net> writes:
>> Based on a glance at the source, it seems like the math libraries
>> were changed in lots of little ways between 2.13 and 2.16 [and it
>> looks like the FPU-twiddling that made expf slow in 2.13 has been
>> _added_ to the generic version of the "exp" (double-precision)
>> function, meaning it might actually be (much) _slower_ in 2.16 on
>> ports without optimized implementations... :( ]
>
> However (if this is the change I'm thinking of) this makes math
> functions "correct" in directed rounding modes and potentially more
> secure.
>
> By "correct", I mean that the result is somewhat acceptable (not
> that the result is correctly rounded and the rounding direction is
> honored), instead of getting completely wrong values or even a
> crash.

But how often are directed rounding modes used?  Like 0.001% of the
time?

So... these functions were made almost an order of magnitude slower in
the (overwhelmingly) common case, in order to handle rare and
exceptional cases...?

I can see that as an emergency workaround when the deadline is next
week, but it seems kind of questionable as a general technique.

Is there no more sane method?

E.g.:

 (1) have the FPU-twiddling functions (<fenv.h> stuff?) set a global
     flag "FPU_is_twiddled = 1;"

 (2) write these rounding-mode-sensitive functions like:

       if (FPU_is_twiddled)
         return slow_ass_FPU_twiddling_version ();
       /* ... otherwise fall through to normal fast code ... */

thanks,

-miles

-- 
Alone, adj. In bad company.