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: