Vincent Lefevre <vinc...@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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d33lhinf....@catnip.gol.com