I think someone should make a betting^H^H^H^H^H^H^H^H futures market of DARPA research ideas, and people can bet on whether they think they'll succeed or not.
I think I know where I'll place my bet^H^H^H.... trade on this Policy Analysis Market idea.:P
It would have been nice if the poster posted a link to the actual microsoft security bulletin, which also links to the patch for your particular DirectX. Also nice would have been a link to this article at eEye security, which goes into much more technical information. What also would have been nice is if the poster specified that the attack only affected MIDI files, instead of implying that all downloads of online music were at risk. The link to the random and not-really-related article about Microsoft protecting its users from legal hassles could probably have been left out, as it just confused the issue.
(Maybe I'm just bitter that my submission of the same story got rejected)
Alright. You keep claiming that NO ONE uses mp3's as a final product, NO ONE accepts the quality of mp3's as good enough for distribution, EVERYONE uses MP3s for promotion ONLY, etc etc.
However, there is plenty of evidence to the contrary -- friends and acquaintances of mine who have huge mp3 collections that they downloaded illegally, listen to, burn onto cds, and use as their primary music collection without even buying the actual cd or paying the artists. I'm not saying all music sharers are like this, but if you're trying to deny that they exist at all, you're gonna have to come up with some MONDO evidence to prove that point. Otherwise, you're living in some sort of strange fantasy that you constructed to make your argument against the RIAA artificially easier.
It seems like a more reasonable position would be to argue that mp3 distribution helps artists with promotional value more than it hurts them through lost sales, then I'd agree with that. But you're saying that people *never* use mp3s as a replacement for buying the album. *EVER*. I can't agree with that.
If you don't think people would pay for MP3's, you obviously haven't seen sites such as http://www.emusic.com/
It doesn't matter to a record sale whether or not the user hears music via P2P or Internet Radio or FM radio, a user has to hear it somewhere before he decides to buy or not to. Why do you buy CDs? If MP3 is "good enough", why not get an artist's address and send him a check for $5 or $10?
Simple: buying the CD is easy and convenient. I'm too lazy to send money to the artist directly. Also, I like the album art.
However, i generally cannot tell the difference between an mp3 and the uncompressed version of a song, unless the mp3 was done *really* badly. Not all consumers have ultra-sensitive audiophile ears. Some of us just like the *music*.
Unfortunately, I can see a lot of PHB's thinking exactly this.
"Gasp! We're using linux for our servers, and now we're gonna get sued! But wait, we just send them a check for $150/computer, and we can avoid all these legal hassles and get on with our business!"
Meanwhile, SCO sits back and reaps in the cash. Sigh.
Let's suppose that SCO's claim is valid and IBM put some code in Linux that shouldn't have been there.
Why are the end users responsible for licensing SCO's code? They got the product (the linux kernel), under a license from the linux developers, and they're following the license they recieved the product from. If there was a license violation, it's on the developer's head (in this case, IBM).
Think about it: If closed source software stole code and sold it, could the company that originally owned the code sue all the users of that code for violating their license? This doesn't make sense to me -- they'd sue the offending closed source company, and perhaps have them issue some sort of recall or licensing program for the code, but they wouldn't go oafter individuals who thought they bought the software legitimately...
How about another example: if a magazine puts some copyrighted content that they're not supposed to use in their magazine, is the copyright owner going to go after every single person who bought the magazine? No! They're going to go after the distributer, who did the illegal *copying* in the first place!
I really don't understand why companies are giving money to SCO under their legal pressure, when it seems like they have absolutely no legal leg to stand on.
anyone know the real legal implications here? IANAL, Obviously:P
--- Clearly, the original poster's conclusion was accurate -- "email" is still the most widely used term on french speaking web sites by an order of magnitude.
"File swapping on P2P is simply distributing the same tracks that the record labels PAY radio stations to broadcast to the public on the dime of the public itself. "
You're confusing performance of the song -- playing it over a radio with very strict rules as to how the listeners can control what they're hearing -- and distribution -- getting a copy of the recording of the specific song you want.
Yes, artists want their songs to get a lot of radio performance so that people will *buy* the actual distributions of the recordings. For many many people out there, mp3 sharing over the internet is not the equivalent of promotional performance, but rather the equivalent of getting the distribution.
You try to write this point off by saying that "128K MP3s are promotional goods of NO commercial value outside their use in getting people to buy the real products." This is simply not true. MP3s are certainly *good enough* for most people as a "real product". Why do you think the online music craze skyrocketed with the mp3 format? I mean, we've had audio compression before then. But it wasn't good enough. Now it is.
And maybe some people don't like the artifacts in a 128K mp3. For many of these people, increasing the bitrate makes it good enough. Where do you draw the line?
You're also concentrating on audio quality, and ignoring a very important aspect -- the *on-demand* nature of distribution. Performance of recorded songs, like I said, has strict controls over the listeners' abilities to choose which songs they hear. Too much control, and it can be considered a song distribution medium, not just a performance one.
--- Anyway, I hate the RIAA. They take too much money out of the whole process purely for profit, charge way too much for CDs, and give the artists way too little of a cut. I do think artists should get paid, but I wish I could do it more directly. I do download illegal music, but if I like it enough, I pretty much always go out and buy the actual CD.
I do think mp3 spreading is helping the popularity of many artists. I do believe that the RIAA's claims of lost money from file sharing are *very* exaggerated, if not completely fabricated.
But I think your assumption that free mp3 sharing is ONLY acting as a promotional tool is a very over-simplified standpoint. Certainly not worth the amount of bold and all-caps text you used on it.
I recall seeing a demonstration of such a system a year ago by a research group at MITRE Corporation that used exactly this kind of idea -- sending the message off to a translation server.
My girlfriend hated snow crash, but absolutely loved cryptonomicon. And she even hates math!
Snow crash is one of his earlier, less developed books. Like he had a cool idea but no story to go along with it. Cryptonomicon is from a much more mature stephenson, at least as a writer -- a very well written, deeply layered and interesting book. Give it a chance:)
Using SIMD instructions is a huge part of the performance of modern processors. Heck, even using SSE2 for scalar arithmetic is faster than using the old 387 instructions.
Saying "disable SIMD -- it's an optimization" is almost like saying "don't use shift instructions for power-of-two multiplies -- it's an optimization". Or "don't keep loop variables in registers -- it's an optimization." If the compiler can do it without weird tweaky flags turned on, then let it be done, i say!
Apple used G5 specific optimizations in GCC. They also used a specialized malloc(), which they didn't use for the PC. Also, they disabled SSE2 on the PC. And hyperthreading on the Xeon. And they used specific hardware tweaks on the G5.
(besides, even if GCC isn't poorly optimized for the x86, one could argue that the NAGWare Fortran compiler, used for most of the floating point tests, is.)
Geez, I looked at the discrepancy between the apple results and the official SPEC results and I thought it was because GCC was having trouble with Intel for some reason. But disabling SSE2 and using the 387 instead? That alone makes the floating point results worthless.
Using a tweaked malloc? Using special hardware prefetch tweaks? Disabling hyperthreading? Gah...
This has nothing to do with reality. GCC is open source. Everybody has access to the GCC source code. It doesn't "suck hard" for Intel. Nor is it ridiculously optimized for PowerPC. It's just a standard compiler.
It's a hypothetical example to show that the "it's the same compiler" argument is bunk. That's why I said "compiler A" and not "GCC".
Actually, that's only generally true on IA-32 processors, where the processor architecture itself is so incredibly bad that unoptimized code runs like ass.
Look at something like the MIPS R10000 family, or the PA-RISC family, or even the PowerPC, and you'll see a very different story.
You are completely off base. *Every* modern processor requires a great deal of optimization to get its full power. Every processor nowdays has to avoid data hazards and load hazards and branch hazards, has to keep several simultaneous functional units full, has to make good use of the cache and precache mechanisms, has to make good use of multiprocessor synchronization primitives, has to make good use of register space... I could go on and on.
In fact, RISC processors have more registers available, allowing a compiler *more* room for optimization, not less.
Actually, the whole *POINT* of RISC was to put more onus on the *compiler* to do the hard work of optimizing things, to make the hardware simpler. Your argument is complete fluff.
"finally, on a somewhat related note, if the speed of specific applications is most important to you, then of course you'd be looking at application benchmarks and not SPEC."
Where Apple also wins the day hands down.
Depending on which application benchmarks you're looking at.
Comparing ICC on Intel to GCC on IBM is *not* a valid test of CPU capability
Neither is GCC on Intel vs GCC on IBM. That was his main point and you didn't address that.
In fact, the only valid test of CPU capability is to optimize the algorithm for the particular processor by hand
This is true. And using the best compiler available for each architecture (ICC for Intel for example) comes much closer to achieving hand-coded efficiency than simply using one compiler across the board, which may suck for particular architectures (GCC for Intel for example).
If distributers of performance-critical binary-only applications for Intel really *should* be using the highest performance compiler available. If they're using GCC one has to wonder if performance is really that important to them.
As for recompiling your own system -- how much of that really *needs* the full power of a 3Ghz multiprocessor machine? How much of a difference will you really see between a P4 and a G5 when doing basic tasks around your system or manipulating windows in XWindow?
Recompiling Gimp, or sound producing software, or 3d modelling software, or video editing/compression software that you may have definitely *would* be worth it, however. And it'd be a lot cheaper than going out and buying a new G5.
Here's the deal: if you want to know how one computer compares to another, you have to use the same compiler.
not true at all. See below.
I mean, you just have to. Otherwise the test is meaningless. You can only test for one variable at a time if you want to get results that mean something.
Say you have compiler A which rocks for architecture A and sucks hard for architecture B. You run SPEC with this compiler, and A wins.
The next day you have compiler B which rocks for architecture B and sucks hard for architecture A. You run SPEC, and B wins.
How are these results meaningful? They say absolutely nothing about the two architectures independent of the compiler used. If you used completely different compiler brands for each architecture, you'd end up with the same thing: Results that are dependent on the compilers used.
The fact of the matter is, cross-architecture comparisons suck no matter what you do. GCC 3.3 for IA32 and GCC 3.3 for the G5 need to be treated as completely different compilers in any valid testing methodology. It doesn't matter that they have the same name and version number -- if they're compiling for different architectures, they're doing things differently. using "the same compiler" to try to feign fairness is simply a sneaky marketing trick.
So what is one to do? Well it depends on the result you want:
-- if you always use GCC 3.3 to compile your high speed apps and want to know which CPU GCC 3.3 works best for, then apple's (Veritest's) results are perfect for you. However, those results really say more about how good GCC is at optimizing for the separate architectures, rather than anything about the merits of the architectures themselves.
-- trying to compare the merits of the architectures themselves is the tricky part. Generally, modern processors need their code to be very well optimized to fully exploit the power of the processor. Therefore, a fair comparison would be between The Best Compiler for Architecture A vs The Best Compiler for Architecture B. This is the only way to even come close to comparing "What architecture A can do" vs "What architecture B can do". And this is what most people want out of a benchmark.
(Of course one has to make sure that the compilers used aren't cheating on the spec benchmarks to give huge results. This is where the base vs peak distinction is important.)
Finally, on a somewhat related note, if the speed of specific applications is most important to you, then of course you'd be looking at application benchmarks and not SPEC.
One more thing: Pipelining is actually a *kind* of parallelism. Gpu's and Vector computers are not only very wide, but generally very *deeply* pipelined. People think of pipelining as only a way to increase clock speed, but it's more accurately a way to have multiple instructions executing simultaneously without having to duplicate hardware. Being able to increase clock speed is just a consequence of this.
The only time shallow pipelines help you are when you have control and data dependencies that cause the pipeline to stall -- iow, when you have non-parallelizable elements. And usually a deeply piplined version with these potential stalls will still run faster than a shorter pipeline -- especially when the code has very few dependencies. Also, how bad your hazards (potential stalls) are to your performance depends more on the structure of your pipeline than simply its length.
Re:Processor design needs to change.
on
P4 3.2GHz Reviews
·
· Score: 1
These chips run at lower clock rates, use less electricity, and move MASSIVE amounts data and calculate a metric ass-load of computations. Processors need wide (128-bit or more) and shallow pipelines to get *the best* performance.
The main reason graphics chips can work so efficiently is because of the *hugely* parallel nature of their operations. You can make things really, really wide and get tons of throughput without much clock speed.
Supercomputer processors -- ie vector processors -- are similar: They rely on huge amounts of parallelism to achieve high performance, and generally aren't clocked very high. This works for scientific computations and simulations and rendering that generally perform identical operations on large, mostly independent slices of data.
Modern desktop processors, on the other hand, are made to deal with sequential instruction streams. Sure, they try to re-order instructions and issue multiple instructions simultaenously and run multiple threads and do every little trick in the book to try to squeeze out all the parallelism possible, but when it comes down to it, there's gonna be a limit to how much width will help you. Most desktop software just can't be parallelized as much as typical scientific code can. The easiest way to increase instruction throughput is to just up the clock.
You're right that just upping the clock incrementally isn't the best solution to performance -- but every computer architect in the world already knows this. Everything in computer architecture nowadays is moving towards more and more parallelism, whether it's instructions in one thread, multithreading, multi processors, or clusters of networked machines.
You fault Intel for needing to change their processor designs and you ignore the fact that they already have -- Remember the Itanium? As much as people love to bash it, its whole point was to create a new architecture to bring VLIW into the modern era. And the whole point of VLIW is to allow parallelism to be more easily uncovered, allowing more performance with slower clock rates.
Also, the newer P4's have hyperthreading support, which is again a way to increase performance through parallelism.
But the bottom line is: in everyday programs, there's still going to be a limit to how much can be made parallel. There's still going to be a need for fast sequential execution and therefore a need for more and more MHz. You say "processor design needs to change" as if parallelizing work is some sort of revolutionary idea, when in fact it's one of the oldest concepts in computer design. It all comes down to what tradeoffs the processor engineers decide to make.
Slashdot Mirror
I think someone should make a betting^H^H^H^H^H^H^H^H futures market of DARPA research ideas, and people can bet on whether they think they'll succeed or not.
.... trade on this Policy Analysis Market idea. :P
I think I know where I'll place my bet^H^H^H
This made me chuckle -- If I hadn't given up my mod points by posting I'd mod you up funny :)
It would have been nice if the poster posted a link to the actual microsoft security bulletin, which also links to the patch for your particular DirectX. Also nice would have been a link to this article at eEye security, which goes into much more technical information. What also would have been nice is if the poster specified that the attack only affected MIDI files, instead of implying that all downloads of online music were at risk. The link to the random and not-really-related article about Microsoft protecting its users from legal hassles could probably have been left out, as it just confused the issue.
(Maybe I'm just bitter that my submission of the same story got rejected)
Alright. You keep claiming that NO ONE uses mp3's as a final product, NO ONE accepts the quality of mp3's as good enough for distribution, EVERYONE uses MP3s for promotion ONLY, etc etc.
However, there is plenty of evidence to the contrary -- friends and acquaintances of mine who have huge mp3 collections that they downloaded illegally, listen to, burn onto cds, and use as their primary music collection without even buying the actual cd or paying the artists. I'm not saying all music sharers are like this, but if you're trying to deny that they exist at all, you're gonna have to come up with some MONDO evidence to prove that point. Otherwise, you're living in some sort of strange fantasy that you constructed to make your argument against the RIAA artificially easier.
It seems like a more reasonable position would be to argue that mp3 distribution helps artists with promotional value more than it hurts them through lost sales, then I'd agree with that. But you're saying that people *never* use mp3s as a replacement for buying the album. *EVER*. I can't agree with that.
If you don't think people would pay for MP3's, you obviously haven't seen sites such as http://www.emusic.com/
It doesn't matter to a record sale whether or not the user hears music via P2P or Internet Radio or FM radio, a user has to hear it somewhere before he decides to buy or not to. Why do you buy CDs? If MP3 is "good enough", why not get an artist's address and send him a check for $5 or $10?
Simple: buying the CD is easy and convenient. I'm too lazy to send money to the artist directly. Also, I like the album art.
However, i generally cannot tell the difference between an mp3 and the uncompressed version of a song, unless the mp3 was done *really* badly. Not all consumers have ultra-sensitive audiophile ears. Some of us just like the *music*.
Rewrite Linux in the clear without reference to the subject code and all is well.
sure thing! Now only if SCO would actually tell everyone what the offending code is, and this will be all behind us!
Unfortunately, I can see a lot of PHB's thinking exactly this.
"Gasp! We're using linux for our servers, and now we're gonna get sued! But wait, we just send them a check for $150/computer, and we can avoid all these legal hassles and get on with our business!"
Meanwhile, SCO sits back and reaps in the cash. Sigh.
Let's suppose that SCO's claim is valid and IBM put some code in Linux that shouldn't have been there.
:P
Why are the end users responsible for licensing SCO's code? They got the product (the linux kernel), under a license from the linux developers, and they're following the license they recieved the product from. If there was a license violation, it's on the developer's head (in this case, IBM).
Think about it: If closed source software stole code and sold it, could the company that originally owned the code sue all the users of that code for violating their license? This doesn't make sense to me -- they'd sue the offending closed source company, and perhaps have them issue some sort of recall or licensing program for the code, but they wouldn't go oafter individuals who thought they bought the software legitimately...
How about another example: if a magazine puts some copyrighted content that they're not supposed to use in their magazine, is the copyright owner going to go after every single person who bought the magazine? No! They're going to go after the distributer, who did the illegal *copying* in the first place!
I really don't understand why companies are giving money to SCO under their legal pressure, when it seems like they have absolutely no legal leg to stand on.
anyone know the real legal implications here? IANAL, Obviously
Your numbers are not accurate -- you got them mixed up.
Here are some *real* numbers, using the same searches as you made (all french language sites):
"courriel" -- 247,000
"courrier électronique" OR "courrier electronique" -- 423,000
email OR e-mail -- 3,050,000
---
Clearly, the original poster's conclusion was accurate -- "email" is still the most widely used term on french speaking web sites by an order of magnitude.
That should be "burnable CD"
I already do pay a tax to the RIAA, every time I buy a burned CD.
;)
So, I figure, If I've bought enough burned CDs, there's no problem with be downloading some free music. No?
"File swapping on P2P is simply distributing the same tracks that the record labels PAY radio stations to broadcast to the public on the dime of the public itself. "
You're confusing performance of the song -- playing it over a radio with very strict rules as to how the listeners can control what they're hearing -- and distribution -- getting a copy of the recording of the specific song you want.
Yes, artists want their songs to get a lot of radio performance so that people will *buy* the actual distributions of the recordings. For many many people out there, mp3 sharing over the internet is not the equivalent of promotional performance, but rather the equivalent of getting the distribution.
You try to write this point off by saying that "128K MP3s are promotional goods of NO commercial value outside their use in getting people to buy the real products." This is simply not true. MP3s are certainly *good enough* for most people as a "real product". Why do you think the online music craze skyrocketed with the mp3 format? I mean, we've had audio compression before then. But it wasn't good enough. Now it is.
And maybe some people don't like the artifacts in a 128K mp3. For many of these people, increasing the bitrate makes it good enough. Where do you draw the line?
You're also concentrating on audio quality, and ignoring a very important aspect -- the *on-demand* nature of distribution. Performance of recorded songs, like I said, has strict controls over the listeners' abilities to choose which songs they hear. Too much control, and it can be considered a song distribution medium, not just a performance one.
---
Anyway, I hate the RIAA. They take too much money out of the whole process purely for profit, charge way too much for CDs, and give the artists way too little of a cut. I do think artists should get paid, but I wish I could do it more directly. I do download illegal music, but if I like it enough, I pretty much always go out and buy the actual CD.
I do think mp3 spreading is helping the popularity of many artists. I do believe that the RIAA's claims of lost money from file sharing are *very* exaggerated, if not completely fabricated.
But I think your assumption that free mp3 sharing is ONLY acting as a promotional tool is a very over-simplified standpoint. Certainly not worth the amount of bold and all-caps text you used on it.
I recall seeing a demonstration of such a system a year ago by a research group at MITRE Corporation that used exactly this kind of idea -- sending the message off to a translation server.
My girlfriend hated snow crash, but absolutely loved cryptonomicon. And she even hates math!
:)
Snow crash is one of his earlier, less developed books. Like he had a cool idea but no story to go along with it. Cryptonomicon is from a much more mature stephenson, at least as a writer -- a very well written, deeply layered and interesting book. Give it a chance
Using SIMD instructions is a huge part of the performance of modern processors. Heck, even using SSE2 for scalar arithmetic is faster than using the old 387 instructions.
Saying "disable SIMD -- it's an optimization" is almost like saying "don't use shift instructions for power-of-two multiplies -- it's an optimization". Or "don't keep loop variables in registers -- it's an optimization." If the compiler can do it without weird tweaky flags turned on, then let it be done, i say!
You're right. But it's even worse: They didn't compare a tweaked Mac to an untweaked PC. They compared a tweaked Mac to a crippled PC.
Apple used G5 specific optimizations in GCC. They also used a specialized malloc(), which they didn't use for the PC. Also, they disabled SSE2 on the PC. And hyperthreading on the Xeon. And they used specific hardware tweaks on the G5.
(besides, even if GCC isn't poorly optimized for the x86, one could argue that the NAGWare Fortran compiler, used for most of the floating point tests, is.)
Geez, I looked at the discrepancy between the apple results and the official SPEC results and I thought it was because GCC was having trouble with Intel for some reason. But disabling SSE2 and using the 387 instead? That alone makes the floating point results worthless.
Using a tweaked malloc? Using special hardware prefetch tweaks? Disabling hyperthreading? Gah...
spec specific optimizaitons which render the benchmarks worthless.
Perhaps you missed the point of "base" vs "peak" scores in SPEC?
Besides, you can use Intel's compiler just fine in the real world, and consistantly get better results than GCC. Even on linux.
This has nothing to do with reality. GCC is open source. Everybody has access to the GCC source code. It doesn't "suck hard" for Intel. Nor is it ridiculously optimized for PowerPC. It's just a standard compiler.
It's a hypothetical example to show that the "it's the same compiler" argument is bunk. That's why I said "compiler A" and not "GCC".
Actually, that's only generally true on IA-32 processors, where the processor architecture itself is so incredibly bad that unoptimized code runs like ass.
Look at something like the MIPS R10000 family, or the PA-RISC family, or even the PowerPC, and you'll see a very different story.
You are completely off base. *Every* modern processor requires a great deal of optimization to get its full power. Every processor nowdays has to avoid data hazards and load hazards and branch hazards, has to keep several simultaneous functional units full, has to make good use of the cache and precache mechanisms, has to make good use of multiprocessor synchronization primitives, has to make good use of register space... I could go on and on.
In fact, RISC processors have more registers available, allowing a compiler *more* room for optimization, not less.
Actually, the whole *POINT* of RISC was to put more onus on the *compiler* to do the hard work of optimizing things, to make the hardware simpler. Your argument is complete fluff.
"finally, on a somewhat related note, if the speed of specific applications is most important to you, then of course you'd be looking at application benchmarks and not SPEC."
Where Apple also wins the day hands down.
Depending on which application benchmarks you're looking at.
Comparing ICC on Intel to GCC on IBM is *not* a valid test of CPU capability
Neither is GCC on Intel vs GCC on IBM. That was his main point and you didn't address that.
In fact, the only valid test of CPU capability is to optimize the algorithm for the particular processor by hand
This is true. And using the best compiler available for each architecture (ICC for Intel for example) comes much closer to achieving hand-coded efficiency than simply using one compiler across the board, which may suck for particular architectures (GCC for Intel for example).
If apple had benchmarked against a Motorola compiler for the G5, and the Intel compiler for the P4/Xeon -- then we'd *finally* have a fair comparison!
Intel's compiler is also commonly available.
If distributers of performance-critical binary-only applications for Intel really *should* be using the highest performance compiler available. If they're using GCC one has to wonder if performance is really that important to them.
As for recompiling your own system -- how much of that really *needs* the full power of a 3Ghz multiprocessor machine? How much of a difference will you really see between a P4 and a G5 when doing basic tasks around your system or manipulating windows in XWindow?
Recompiling Gimp, or sound producing software, or 3d modelling software, or video editing/compression software that you may have definitely *would* be worth it, however. And it'd be a lot cheaper than going out and buying a new G5.
Here's the deal: if you want to know how one computer compares to another, you have to use the same compiler.
not true at all. See below.
I mean, you just have to. Otherwise the test is meaningless. You can only test for one variable at a time if you want to get results that mean something.
Say you have compiler A which rocks for architecture A and sucks hard for architecture B. You run SPEC with this compiler, and A wins.
The next day you have compiler B which rocks for architecture B and sucks hard for architecture A. You run SPEC, and B wins.
How are these results meaningful? They say absolutely nothing about the two architectures independent of the compiler used. If you used completely different compiler brands for each architecture, you'd end up with the same thing: Results that are dependent on the compilers used.
The fact of the matter is, cross-architecture comparisons suck no matter what you do. GCC 3.3 for IA32 and GCC 3.3 for the G5 need to be treated as completely different compilers in any valid testing methodology. It doesn't matter that they have the same name and version number -- if they're compiling for different architectures, they're doing things differently. using "the same compiler" to try to feign fairness is simply a sneaky marketing trick.
So what is one to do? Well it depends on the result you want:
-- if you always use GCC 3.3 to compile your high speed apps and want to know which CPU GCC 3.3 works best for, then apple's (Veritest's) results are perfect for you. However, those results really say more about how good GCC is at optimizing for the separate architectures, rather than anything about the merits of the architectures themselves.
-- trying to compare the merits of the architectures themselves is the tricky part. Generally, modern processors need their code to be very well optimized to fully exploit the power of the processor. Therefore, a fair comparison would be between The Best Compiler for Architecture A vs The Best Compiler for Architecture B. This is the only way to even come close to comparing "What architecture A can do" vs "What architecture B can do". And this is what most people want out of a benchmark.
(Of course one has to make sure that the compilers used aren't cheating on the spec benchmarks to give huge results. This is where the base vs peak distinction is important.)
Finally, on a somewhat related note, if the speed of specific applications is most important to you, then of course you'd be looking at application benchmarks and not SPEC.
wide (128-bit or more) and shallow pipelines
One more thing: Pipelining is actually a *kind* of parallelism. Gpu's and Vector computers are not only very wide, but generally very *deeply* pipelined. People think of pipelining as only a way to increase clock speed, but it's more accurately a way to have multiple instructions executing simultaneously without having to duplicate hardware. Being able to increase clock speed is just a consequence of this.
The only time shallow pipelines help you are when you have control and data dependencies that cause the pipeline to stall -- iow, when you have non-parallelizable elements. And usually a deeply piplined version with these potential stalls will still run faster than a shorter pipeline -- especially when the code has very few dependencies. Also, how bad your hazards (potential stalls) are to your performance depends more on the structure of your pipeline than simply its length.
These chips run at lower clock rates, use less electricity, and move MASSIVE amounts data and calculate a metric ass-load of computations. Processors need wide (128-bit or more) and shallow pipelines to get *the best* performance.
The main reason graphics chips can work so efficiently is because of the *hugely* parallel nature of their operations. You can make things really, really wide and get tons of throughput without much clock speed.
Supercomputer processors -- ie vector processors -- are similar: They rely on huge amounts of parallelism to achieve high performance, and generally aren't clocked very high. This works for scientific computations and simulations and rendering that generally perform identical operations on large, mostly independent slices of data.
Modern desktop processors, on the other hand, are made to deal with sequential instruction streams. Sure, they try to re-order instructions and issue multiple instructions simultaenously and run multiple threads and do every little trick in the book to try to squeeze out all the parallelism possible, but when it comes down to it, there's gonna be a limit to how much width will help you. Most desktop software just can't be parallelized as much as typical scientific code can. The easiest way to increase instruction throughput is to just up the clock.
You're right that just upping the clock incrementally isn't the best solution to performance -- but every computer architect in the world already knows this. Everything in computer architecture nowadays is moving towards more and more parallelism, whether it's instructions in one thread, multithreading, multi processors, or clusters of networked machines.
You fault Intel for needing to change their processor designs and you ignore the fact that they already have -- Remember the Itanium? As much as people love to bash it, its whole point was to create a new architecture to bring VLIW into the modern era. And the whole point of VLIW is to allow parallelism to be more easily uncovered, allowing more performance with slower clock rates.
Also, the newer P4's have hyperthreading support, which is again a way to increase performance through parallelism.
But the bottom line is: in everyday programs, there's still going to be a limit to how much can be made parallel. There's still going to be a need for fast sequential execution and therefore a need for more and more MHz. You say "processor design needs to change" as if parallelizing work is some sort of revolutionary idea, when in fact it's one of the oldest concepts in computer design. It all comes down to what tradeoffs the processor engineers decide to make.