Vincent Lefevre <vinc...@vinc17.net> writes: > But with: ... > int r = fegetround(); > if (r != FE_TONEAREST) > fesetround (FE_TONEAREST); > y = exp(x); ... > I only get a 9% slowdown. I suppose that withing glibc code, it can > be lower.
Makes sense... I can imagine the way overworked CPU designers not bothering to optimize mode setting at all (e.g.., just flush all pipelines when it happens...), on the assumption that setting the rounding mode is a very rare operation... > The advantage of this method compared to remembering the > rounding mode in glibc is that it is 100% safe, in case the user or > some library bypasses the C libary to change the rounding mode. > > I think that there could be an optimization like that in > fesetround() too. Do you think it's worth proposing this to the glibc people? [I'm always a little scared to do that, nest of vipers, etc...] -miles -- In New York, most people don't have cars, so if you want to kill a person, you have to take the subway to their house. And sometimes on the way, the train is delayed and you get impatient, so you have to kill someone on the subway. [George Carlin] -- 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/87pq7jf8et....@catnip.gol.com
