>The DEC Alpha had/has some custom libraries for it which were tuned
>for the Alpha. It apparently was way faster than dumb old libm.a
>Has anyone bothered to write some of these for the new P III SSE
> (SIMD+MMX) or G4 AltiVec units?
>Libraries like that could really speed up JPEG/MPEG and OpenGL stuff
>on Linux as well as make it a better scientific system now that
> P III and Athlons are so fast. It would be nice to put SGI out
>of their misery and have another reason not to buy a Sun for those
>floating point users out there.
>I don't know how much kernel support is needed to allow these things to
>work. The old MMX *was a waste and took forever to switch modes. I
>would assume that Intel fixed that for the new stuff and that Motorola
>did it right in the first place. It should be a bunch of save
>system state calls when you interrupt a vector calculation so that
>would mean Kernel support just to get the libraries working.
There is a notable distinction between IA-32 and Alpha (and I can't
speak for PPC):
IA-32 has FP instructions specifically for trig and transcendental
The "original" libm.a for Alpha was coded in C, wasn't terribly tuned,
and provided rather slower performance than you'd get with the
hardware FP instructions on IA-32.
It was *extremely* worthwhile to hand-craft these functions in Alpha
Note that this has nothing to do with MMX, AltiVec, or the Alpha
equivalent (whose name escapes me...).
There is merit to creating libraries to try to take advantage of
"MMX-like" technologies; I suspect they'd need to be fairly
I expect there would be merit to having some MMX/ 3DNow/ AltiVec/
... support in XFree86, but it's not worth *thinking* about 'til
XFree86 4.0 is actually released.
"Using Java as a general purpose application development language is
like going big game hunting armed with Nerf weapons."
-- Author Unknown