My point is that we would be comparing compilers more than comparing CPUs. This of course it the problem with SPEC- it is a comparison of compiler + CPU, although there is no way to seperate the two nowadays. Making a vectorizing compiler (which I am all in favor of) would simply muddy the already muddied SPEC benchmarks. Of course, if PPC+vector compiler could beat intel + intel compiler, then Apple could at least say that they have a better CPU+compiler combo. Of course, the intel folk would just say that the vectorizing compiler was giving artifically high SPEC results.
I think a good counterargument can be made. SPEC is not intended to be a theoretical benchmark. It's an attempt to run real-world tasks on a platform (CPU + compiler) and measure the performance. Auto-vectorization is simply an compiler adaptation to a recent trend in CPU design, just as OOE is a recent CPU adaptation to compiler output. The compiler and CPU cannot be cleanly separated. And, if Apple's going to ship a version of GCC with autovectorization enabled by default, then running the SPEC suite with that compiler and those settings is the most straightforward use of the benchmark - real-world uses of a n platform in actual use - that one could argue for, while the trend Intel has encouraged could be argued to be the artificial one. Apple is not "benchmark engineering" in this case; Intel is.
Essentially, the argument against compiler autovectorization boils down to the obvious fact that it favors architectures with better SIMD engines, i.e. not x86. I don't see autovectorization as "cheating" by the compiler any more than OOE is "cheating" by the CPU. If the platform executes the outcome intented by the code, I don't understand how "cheating" is even meaningful in the context of what SPEC is trying to measure. If a real-world platform correctly gzips a given file using a given program in X amount of time, that's all you need to know. That's what SPEC is intended to measure in the first place.
Eric_Z, the POWER5 (and all POWERs) are designed for reliability. A 130nm process insn't all that bad on a POWER5. The thicker switches are more reliable, but can't switch as fast. This is why moving to 90nm on the 970 will instantly give us a speed boost. Also, with the POWER5 at 130nm, there's more silicon, hence more expensive. At 90nm, less silicon sits between two points so you don't need as much power and save some heat, hence, at 90nm we could theoretically put a 1.8Ghz 970 in a PowerBook because it would use less power, be cheaper (smaller more per wafer), less hot, and get the same as the current 970 on CPU basis.
What interests me is that IBM claims an quadrupling of the preformance over POWER4+, but it only expected to ship initially with a max clockspeed of 2Ghz, ca 12% more then what the POWER4+ is currently capable of scaling to.
According to IBM the first servers based on its next generation POWER5(TM) microprocessors [snip] are expected to offer four times the system performance over the first POWER4(TM) based servers [snip] Based on IBM internal performance measures.
IBM claims to have protoypes of the next generation. It's usually 12-18 months from first silicon to production, no? Now the question would be, do they mean the 90nm 970, or the POWER5-derived CPU we're calling the 980, or something else?
In the early articles on Fishkill, IBM seemed impatient to get to 90nm. I seem to remember something about "months". So, given that IBM appears to be justifiably optomistic about its fab's capabilities, I'm expecting a shorter than average lifespan for the 130nm 970. But not for the 970 itself. I don't remember reading any approximate timeline for the POWER5 to appear.
Forget where I read it, but IBM was trying for a Sept '03 timeframe for the 90nm. Just not sure if that was production or not. I've also heard that they're producing 90nm chips, just not CPU type silicon, and not sure if it was at "Fishkill" or not. FWIW
Comments
Originally posted by Yevgeny
My point is that we would be comparing compilers more than comparing CPUs. This of course it the problem with SPEC- it is a comparison of compiler + CPU, although there is no way to seperate the two nowadays. Making a vectorizing compiler (which I am all in favor of) would simply muddy the already muddied SPEC benchmarks. Of course, if PPC+vector compiler could beat intel + intel compiler, then Apple could at least say that they have a better CPU+compiler combo. Of course, the intel folk would just say that the vectorizing compiler was giving artifically high SPEC results.
I think a good counterargument can be made. SPEC is not intended to be a theoretical benchmark. It's an attempt to run real-world tasks on a platform (CPU + compiler) and measure the performance. Auto-vectorization is simply an compiler adaptation to a recent trend in CPU design, just as OOE is a recent CPU adaptation to compiler output. The compiler and CPU cannot be cleanly separated. And, if Apple's going to ship a version of GCC with autovectorization enabled by default, then running the SPEC suite with that compiler and those settings is the most straightforward use of the benchmark - real-world uses of a n platform in actual use - that one could argue for, while the trend Intel has encouraged could be argued to be the artificial one. Apple is not "benchmark engineering" in this case; Intel is.
Essentially, the argument against compiler autovectorization boils down to the obvious fact that it favors architectures with better SIMD engines, i.e. not x86. I don't see autovectorization as "cheating" by the compiler any more than OOE is "cheating" by the CPU. If the platform executes the outcome intented by the code, I don't understand how "cheating" is even meaningful in the context of what SPEC is trying to measure. If a real-world platform correctly gzips a given file using a given program in X amount of time, that's all you need to know. That's what SPEC is intended to measure in the first place.
Originally posted by ast3r3x
I'll stick with the ferrari with 2 gears as its pretty powerful engine but can't transfer enough of its power to the car (system)
Eh, I'd say its more like flooring the gas pedal but the engine isn't getting enough gas.
Originally posted by Eric_Z
The latest info regarding POWER5 from The Register:
http://www.theregister.co.uk/content/3/31467.html
What interests me is that IBM claims an quadrupling of the preformance over POWER4+, but it only expected to ship initially with a max clockspeed of 2Ghz, ca 12% more then what the POWER4+ is currently capable of scaling to.
According to IBM the first servers based on its next generation POWER5(TM) microprocessors [snip] are expected to offer four times the system performance over the first POWER4(TM) based servers [snip] Based on IBM internal performance measures.
Originally posted by Amorph
IBM claims to have protoypes of the next generation. It's usually 12-18 months from first silicon to production, no? Now the question would be, do they mean the 90nm 970, or the POWER5-derived CPU we're calling the 980, or something else?
In the early articles on Fishkill, IBM seemed impatient to get to 90nm. I seem to remember something about "months". So, given that IBM appears to be justifiably optomistic about its fab's capabilities, I'm expecting a shorter than average lifespan for the 130nm 970. But not for the 970 itself. I don't remember reading any approximate timeline for the POWER5 to appear.
Forget where I read it, but IBM was trying for a Sept '03 timeframe for the 90nm. Just not sure if that was production or not. I've also heard that they're producing 90nm chips, just not CPU type silicon, and not sure if it was at "Fishkill" or not. FWIW