Urs wrote:Some light on this:Borogove wrote:Looks like they don't even try to emulate Altivec in Rosetta - I'm guessing Rosetta presents to the OS as an CPU which does not support Altivec, so well-behaved apps that check for Altivec support and fall back to straight FPU sequences should be OK. (I think emulating PPC FPU on x87 FPU would be faster than emulating PPC Altivec on any combination of x87/SSE).slasi wrote:1) Altivec optimized stuff will a lot harder to port. Which is most audio stuff. My guess is emulation of altivec instructions won't be fast enough.
As far as I can see, the most used AltiVec code for audio processing is Apple's Veclib. Veclib is a library of highly optimzed routines, such as FFT/iFFT. In addition, Apple offers super fast vector routines for matrix operations (blast), trigonometric functions (vecfpsomething) and stuff. As long as you use these, you do not have to port anything, because these libraries have already been maintained in SSE/SSE2 flavour. They are simply available (for free, btw.).
Next, a bit I gathered from CoreAudio team, just like planned for Longhorn, Mactel will not use the Intel FPUs. All floating point calculation will be done in the SSE layer, which is supposed to be a dramatic speed boost even for scalar operations. Add to that, the Apple compiler does auto vectorization, so that your scalar code will benefit from parallel processing whenever possible.
I guess the minimum requirements for a Mactel cpu is the availability of SSE2. While that's probably still a joke compared to AltiVec, there's kinda migration guide on developer.apple.com that has a conversion table. I suppose that there'll be an alternative for most vector calculations pretty soon, so that the developers can mostly just copy/paste the stuff if they have custom vector code.
One thing where AltiVec sucks is 64 bit - it simply can't do this. AFAIK SSE2 does double precision... this is something I'm really looking forward to, because a lot of my dsp code is 64 bit and I couldn't vectorize it at all... (well, I don't have to on a G5 because of its 2 FPUs)
Cheers,
Urs
Damn nice post.
So my question is:
1. If OSX/x86 use SSE2 rather than x87 for FP ops, wouldn't it be possible that Rosetta can have some slick JIT optimization that autovectorize G3 binaries to SSE2 operations?
2. You mentioned VecLib. Presumably, Rosetta is like Linux-on-Linux Qemu -- there's an x86 binary emulator, and then there's an 1-to-1 OSX/PPC API to OSX/x86 API userland translation layer. If an OSX/PPC app calls an OSX API function, it should just be translated to the equilvalent API call in OSX/x86 and handled natively. So, if an OSX/PPC app calls VecLib in Rosetta, wouldn't it be translated and executed natively in x86 with all its SSE2-optimized glory??? (I know that's a pretty big assumption though since the endianess issue can make vector translation a lot more complicated.)
Then maybe Altivec emulation is just not neccessary at all.
