[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: glibc very old

Vincent Lefevre <vincent@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 ...


Circus, n. A place where horses, ponies and elephants are permitted to see
men, women and children acting the fool.

Reply to: