On 2012-07-24 13:45:08 +0900, Miles Bader wrote: > Vincent Lefevre <vinc...@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 <vinc...@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) -- 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/20120724090651.ga6...@ypig.lip.ens-lyon.fr
