First off, apologies that i got a bit over sensitive with the spelling. You are right, in that if you want to make a point make it easy for readers to read it. Mates
you see the point isn't whether one chip can one a nano second faster than another. on present day apps i don't care because certainly for a lot of modern apps, a xeon , opteron or G5 is extreme overkill. Hell there are things that a 600MHz G4 is over kill for.
The issue is more along the lines of which chip has the greatest potential and will more than likely rule the roost in a particular discipline in industry. These really are the only people presently that can appreciate the perf. majority of users running word won't see a diff between a G5 and G4 and G3. However industry where time is money, it is important. Regardless of todays perfoormance of the G5; whether it is overall *twice* as fast as the x86 equiv as apple would have you believe, or whether its actually neck and neck in a lot of stuff. When it does go ahead of the x86 in a benchmark it tends to do it in leaps and bounds in order of magnitude. For example some of the photoshop results, if you are a pro, then the G5 would seam to be the chip for you. If you are into digi vid editing, G5 can now do 7 streams with only a plugin. nearest xeon equiv can only manage about 4 or 5 on a pc equiv application.
The point is really that, Opteron and Xeon (particularly Xeon) are running extremely optimized code these days what with SSE2 etc... support widespread in apps. The opteron very cleverly on amd's part does have room for extra performance, in 64 bit mode, but then so does the G5. In its 32 bit mode software is as optimized as it can get for it presently. The opteron is heavily based on the athlon, it uses the same fpu and int units as the athlon xp, it adds (on die memory controller) SSE2 extensions and x86-64 extensions. Its core units int, fpu and scheduler is essentially that of an athlon xp. SSE2 is widespread in software now thanks to intel needing to push its adoption so that the P4 could perform. Looking at SUSE AMD 64 which we run in work, the opteron gains about 10 ->15 percent for 64bit mode. Rumor has it that Pathway software are working with AMD on an extremely optimized 64 bit compiler for x86 64 mode. Supposedly it produces 40% improvements in a few tests with the majority of tests gaining 15% extra speed over a already heavily optimized GCC for x86.
You see what i am getting at, is that presently the PPC970 is RADICALLY different to any PPC that came before. Architecturally the chip was built for extremely high performance and extreme parallelism. Case in point is the fact that it can issue so many instructions for execution, that it can retire so many intructions, that it has so many more registers, that it has dual COMPLEX fpu, integer units, that it can have 215 instructions in flight. These weren't just put there by IBM as a marketing tool. This chip was designed for real world performance. Having been to the IBM developer conf last year and talking to the designers present, i can assure you, they explicitly were targeting future performance. Its raw brute horse power is allowing the PPC970 to compete extremely favorably with x86 presently. But when you do use a compiler that can generate code that uses its extremely advanced scheduler to saturate the pipes, that can generate code that runs on dual int and dual fpu pipes in parallel you get literally double or tripple the performance of what you get from an equivalent x86 running with an optimized compiler. Currently as i already quoted ars on... PPC970 is best case scenario in the majority of time running at 50% efficiency. The IBM compilers are able to use all the bells and whisles which are present in the chip which are completely unexploited by GCC or any other compiler available for the G5 presently. Then there is the fact that the G5 incorporates a much much more advanced vector processing unit than the opteron or Xeon. It has the potential to improve performance when used in orders of significant magnitude. Current compilers including GCC have not and do not autovectorise like they do for x86.
Furthermore historically x86 has had far better optimizations within GCC than PPC. the 970 being so new has had so little done for it within GCC that we are sitting on raw brute performance which is keeping us up with the fastest x86 money will buy.
Now consider this. Chip technology this time around is different for Apple. Reason for this is their partnership with IBM. IBM are using the 970 in their own highend workstations and blade servers. IBM obviously are heavily supporting the G5 especially in light that they are offering a beta version of their compilers for Mac OS X. Apple never had that type of support from Motorola. Now consider that IBM has plans to incorporate autovectorisation in their compilers since their own blade servers will incorporate the altivec technology. Autovectorisation alone will yield massive performance increases.
But lets forget the autovectorisation for a moment. Scientists at NASA recompiled their JET3D application with the IBM compiler and were shocked at the results.
Integer scores rose nearly 80% over what GCC was giving them. Scaler fpu rose to over 210% what best case scenario GCC was giving them, and vector alitvec results rose 70% over what GCC was giving them.
Other tests in the arstechnica forums reported similar experiences except in one or two cases... out of many extremely successful cases where XLF was 2 or 3 times faster than GCC, there were 2 cases where XLF and XLC was slightly slower than GCC. After a lot of debate in the forums these 2 anomolies were put down to the extremely beta status of the compiler.
AFAIK we are still talking 32 bit mode PPC970
Its widely known that theoretically the 970 has significantly higher performance than an equivalently clocked Opteron.
When a proper compiler like the XLF and XLC are used this theoretical becomes reality.
When GCC is used and "incompatible" or non efficient compiler is used it only operates at 50% peak theoretical performance.
Todays "optimized apps" have a huge way to go in terms of tapping into the 970 in 32 bit mode let alone 64 bit mode
For a start start using the IBM compiler until GCC becomes better optimized. Thats not to dish on GCC, im sure it will improve and its extremely like that from here on in the performance we get out of 970 in each GCC revision will be better in leaps and bounds.
The point is that its amazing that in a worst case scenario these days (GCC being used on legacy code) that the G5 is able to keep up with and beat in some instances the best that the x86 can throw at it.
Now that OS X is unix based you can download the source yourself and compile with XLC or XLF in some cases (most modern apps are written in C so more than likely 90% of time you will be using XLC). If you do this you will see what im talking about. Performance in most cases doubles or tripples what GCC can do. Proves exactly what ars was saying. In my opinion raw brute horse power on legacy apps makes it extremely competetive with the fastest optimized x86 apps. Use the optimized equiv compiler for the 970 and you got the fastest PC full stop. Think if performance improves significantly with GCC by a recomile, imagine what you are getting when you recompile with XLC.
On a side note, apple will probably have to redo their spec results. IBM will be publishing spec results for their blades when finalised and are likely to blow apples results out of the water, even though both use the same chip on similar hardware! It will look strange when an IBM dual 1.6 blade blows the nickers of a dual 2GHz G5 in spec fpu and spec int, all because apple used GCC! By the way incase you are wondering IBM compilers presently generate GCC compatible results and are eligible to be used for compiling SPEC.
Now show me an x86 chip that has this potential performance waiting to be tapped under the hood.
Phew ... im wrecked ....end rant!
