[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: glibc very old

On 2012-07-24 13:45:08 +0900, Miles Bader wrote:
> Vincent Lefevre <vincent@vinc17.net> writes:
> > 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?

They are not used often. However they must be correct.

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

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

There's only one code, which is run in both cases. The difference
is that the rounding mode is set to FE_TONEAREST at the beginning
of the function and restored at the end of the function.

The only sensible change that can be done (without requiring the
compiler a choice based on the FENV_ACCESS pragma) is to test a
global (actually TLS) flag as you propose so that the instruction
to control the rounding mode is not used if the processor was
already in FE_TONEAREST. But note that this could actually be
slower with some processors: the processor already knows the
rounding mode it is running under, so that if the rounding mode
is not changed, the rounding-mode control instruction should be
no slower than no-op!

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)

Reply to: