Re: glibc very old
Vincent Lefevre <vincent@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]
Reply to: