Vincent Lefevre <vinc...@vinc17.net> writes: >> 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).
It's about 5 times slower on both phenom2 (AMD) and core2 (Intel) cpus.... I dunno if these are unusual. > 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! Ok, I guess there's no really guaranteed way to make it fast, so glibc's method (with arch-specific reimplementations for those cases where it proves to be slow) it is reasonable enough ... -miles -- Circus, n. A place where horses, ponies and elephants are permitted to see men, women and children acting the fool. -- 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/87vchbfz1i....@catnip.gol.com
