>> Another question: does your application do sqrt() a lot, by
>> chance? The old sqrt implementation was a real dog (it computed
>> the result a bit at a time!).
Kawai> sqrt() is not the only fuction which is slow on Linux/Alpha:
Kawai> CTIME/OPERATION
Kawai> ==========================================================================
Kawai> CPU CLOCK OS CC atan sqrt log exp sin
Kawai> (MHz) (ms) (ms) (ms) (ms) (ms)
Kawai> --------------------------------------------------------------------------
Kawai> 21164 300 WinNT-3.51 vc++ 0.346 0.287 0.221 0.402 0.637
Kawai> 21164 300 Linux-1.99.5 DEC-C 0.332 0.302 0.272 0.463 0.675
Kawai> 21164 300 OSF1-3.2 DEC-C 0.338 0.305 0.273 0.465 0.632
Kawai> 21164 300 Linux-1.99.5 gcc-2.7.1 0.841 0.403* 1.258 0.877 2.937
Kawai> PA-7100 125 HP-UX-9.05 HP-C-9.73 0.658 0.237 0.661 1.314 0.998
Kawai> i586 166 Linux-1.2.13 gcc-2.7.2 0.904 0.560 0.917 1.374 0.833
Kawai> ==========================================================================
Kawai> * assembler version.
Well, it looks like Linux with DEC-C is doing pretty well... :-) (I
assume what you mean for that entry is: Linux running the DEC
libraries compiled with DEC C---I doubt the old libm library compiled
with DEC C would be that fast.)
In general, I think everybody would welcome if somebody who cares and
knows about fp-intensive apps would spend some time on improving the
math library (if you would like to do so, please start with the one
that comes with glibc---it's a much better starting point than the old
glibc).
For those who haven't done so in a long time: I'd recommend re-reading
the first paragraph of http://www.azstarnet.com/~axplinux/FAQ-1.html.
Yes, optimization is a big issue.
Cheers,
--david