Vincent Lefevre <email@example.com> 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
> 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
But how often are directed rounding modes used? Like 0.001% of the
So... these functions were made almost an order of magnitude slower in
the (overwhelmingly) common case, in order to handle rare and
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?
(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:
return slow_ass_FPU_twiddling_version ();
/* ... otherwise fall through to normal fast code ... */
Alone, adj. In bad company.
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org