PPC970FX said:
Okei do you think that they would say that they changed to a weaker vector extension? They just can not say that.
You mean Apple is lying to us all?
PPC970FX said:
And you mean future X86-64 right?
SSE3 is in current Netburst (32-bit and 64-bit), and it will be in Yonah/Merom/Conroe and all new chips. Dothan (the current Pentium M) uses SSE2.
SSE3 is very similar to SSE2, but adds a dozen or so new instructions. In general SSE2 and SSE3 are comparable, but SSE3 can be faster for some application (e.g. SSE3 can do vector calculation on imaginary numbers - very useful for some codes).
See
http://www.intel.com/technology/itj/2004/volume08issue01/art01_microarchitecture/p06_sse.htm for an in-depth description of the new SSE3 instructions.
SSE2 and SSE3 are in both 32-bit and 64-bit chips. (Intel's 64-bit chips are SSE3, AMD has both SSE2 x64 and SSE3 x64.)
One difference with x64 is that there are 16 of the 128-bit SSE registers when in 64-bit mode, vs 8 registers when in 32-bit mode. This means that 64-bit SSE code should be somewhat faster than 32-bit code in most cases.
PPC970FX said:
My point is just that AltiVec is not practical to emulate, since it is a hardware feature.
It is *very* practical to emulate, otherwise a program that requires AltiVec can't be run on x86.
Even scalar emulation (emulating AltiVec with standard scalar instructions) is better than nothing for many people.
It is possible, however, for Rosetta to "convert" AltiVec code to vector SSE code - to convert one hardware feature to another. This would not only let you run AltiVec code on x86, but run it at hardware accelerated speeds. That would be big.
(Note: I have no information to confirm that the rumours of AltiVec support in 8F1111 Rosetta are true, let alone confirm whether it's a scalar or vector emulation.)
PPC970FX said:
I think that AltiVec is more powerfull in general then SSE3. But I can understand that some people think that it is the other way around. Then we can agree to disagree.
I won't disagree that the AltiVec implementations in the MPC7xxx and PPC970x are more powerful than the SSE2/3 implementations in the Netburst/PentiumM chips.
The main reason is that AltiVec has been implemented with a parallel ALU to perform the operations, and Intel (so far) uses the scalar ALU (pushing the separate operations quickly into the pipeline). Intel's approach is better than scalar code in the application, but not as good as having a separate parallel ALU.
In the future, however, Intel could put one or more vector ALUs into the chip, and run SSE2/3 operations truly in parallel. This could be completely, absolutely compatible with existing SSE programs.
The architecture defines the behaviour of the SSE instructions, not whether the actual implementation uses scalar, parallel or multiple execution units to produce that behaviour.
We don't know what tricks Intel has planned for the huge numbers of transistors in the new chips - but they could decide to spend some of those transistors to make an SSE3 implementation that puts the current AltiVec implementations to shame.
____________
The landscape is changing for SSE as well.
Currently, SIMD use is hampered by the several different implementations of current systems in the installed base (MMX/SSE/SSE2/SSE3). It's a pain to test for the different capabilities. Compilers can automatically generate vector code, but they don't generate all 5 versions with the necessary runtime tests.
In the x64 world, however, every system is guaranteed to be at least SSE2 compatible. Developers can use SSE2 without checking. This will give Intel more incentive to improve the SSE implementation in silicon, since the SSE units may be used much more often in 64-bit code.
