iMac G5 / PowerMac G5 performance

ElDiabloConCaca said:
Yep, and that's something I've thoroughly "preached" to those that will listen... :D

...but the question is, "Why?" Is it CISC vs. RISC or some variant thereof? Is it because we have more registers to work with, and, if so, is that still true of the G5 and the AMD/Intel processors?
Click to expand...

A lot of it has to do with the pipeline length of the processor. RISC CPUs tend to have very short instruction pipelines while CISC CPUs tend to have longer pipelines. Incidently, Arstechnica recently had a series of articles on pipelining and they can explain this a lot better than I can, in simple terms for the lay person. Which I think is great! http://arstechnica.com/paedia/p/pipelining-1/pipelining-1-1.html

Somewhere on that site is also quite possibly one of the best expositions of the G5 architecture. I really recommend reading the articles on that site, to get a general knowledge of the current crop of CPUs be it from Intel, AMD or IBM. They cover and explain them really well. If you're keen on knowing more about CPUs in general, Computer Organization and Design by Patterson and Hennessey is a book I swear by. Even I understood it ;)
 
Lycander said:
Actually it's very much scientific. Those 2 machines you mention are both running in 32 bit mode. The G5 system is ~600MHz faster (per CPU) than the G4 system, and has a faster system bus. So it's a no brainer that the G5 is better in your comparison, you could have just stopped at "it has more MHz" and call it a day.
Click to expand...

Oh, I know. The person who was talking with me was not familiar with the G5, oddly enough. It was months after the launch and they work in IT as well. It was more of a comparison of high end x86 architecture to high end Apple branded PPC architecture, for desktops.

His comment was that 64-bit could actually slow down the machine, as if the application is simply sending 32-bit chunks of data, that the CPU simply processes an extra 32-bits of blank info. My response back was, that I didn't care if it did, or didn't do that, being that the bus, etc was such a huge step forward. :)

Remember, to people who are unaware of the new breed of Apple offerings, most will still assume 100-133MHz FSB and, if they knew beyond that, shared bus between the cpu's as well. So explaining that 2GHz wasn't smoke and mirrors, is more than just saying "its faster". :)
 
Viro said:
A lot of it has to do with the pipeline length of the processor. RISC CPUs tend to have very short instruction pipelines while CISC CPUs tend to have longer pipelines.
Click to expand...
CISC vs RISC has nothing to do with pipeline lengths. Intel (and to some extent AMD) choose to use longer pipelines in order to scale their chips higher in MHz, that's all a marketing ploy, bad Intel!

The whole "shorter" pipeline argument is getting kinda old and irrelevent now a days.

http://www.cpuplanet.com/features/article.php/2233261

but where the G5 really pummels its predecessor is in pipeline length: Instead of the original G4's 4-stage or G4+ chip's 7-stage integer pipeline, the PowerPC 970 follows the superpipelined approach of the 20-stage Pentium 4 with a 16-stage integer pipeline -- 21 stages for floating-point instructions, as many as 25 stages for single-instruction-multiple-data (SIMD) multimedia instructions.

So there's more than one pipeline to be concerned with, but we typically hear chip companies touting the smallest number. Back when Apple was showing that presentation about pipeline length, that shorter is better, it only showed one side of the story. The whole idea behind pipelining is to constantly feed instructions and data to the CPU. The presentation illustrated this with little circles (or something) marching through a "pipeline" and when the nasty ol' branching instruction came along it forced the pipeline to flush and everything has to be reloaded.

Yes that does sound like a performance bottleneck. But what the presentation neglects to show is that the x86 rivals often had double the bus speeds of the G4. So what if they had to flush a 20 stage pipeline. The bus speeds were running almost 4 times faster than the G4's that it could flush and refill the pipeline and the penalty is not as bad as Apple makes it out to sound.

With the G5 we start seeing real improvements in bus speeds and how fast it can move data. The PPC architecture is a great number crunch, no doubt. But it was starving for data on a 133 MHz bus. Putting DDR RAM in a G4 system is completely USELESS because the G4 CPU and chipset was not designed for DDR. Going from a pipeline length of <10 stages (G4) to double digits (G5) didn't wreck performance did it? But the result? Higher clock speeds, 2+ GHz. And with the faster FSB and overall system bus, it can flush and refill the pipeline without a hitch. But that's what CPU cache is for, that's what prefetching is for. I'm more concerned with the branch mis-predict features more so than pipeline depth. AMD chips as well as IBM chips have very good branch mis-prediction handling, so they don't suffer too much when branching code causes the CPU to mis-predict the next instruction location. Intel's CPUs are notoriously crappy at branch mis-prediction, that's why everyone else could stomp a P4 in certain tests.
 
I certainly don't have as good of an understanding of cpu function as you guys do, but if running 64 bit code is slower than running 32 bit, how come 32 bit is faster than 16? Why wern't these problems encountered when going from 16 to 32? Does the technology just need to be perfected?
 
HateEternal said:
I certainly don't have as good of an understanding of cpu function as you guys do, but if running 64 bit code is slower than running 32 bit, how come 32 bit is faster than 16? Why wern't these problems encountered when going from 16 to 32? Does the technology just need to be perfected?
Click to expand...

The overhead incurred by going to 32 bits greatly offset the disadvantages of 16 bit processors. Back in the days of 16 bit processors and OSes, a lot of hacking was done in order to get the CPU to recognize more than 64K of RAM (2^16 = 65536). Most OSes got around this by using a segmented memory model, where the RAM in a computer was divided into segments of 64 KB each.

This effectively meant that the computer could only effectively work with 64 KB of RAM at a time. You could access more, but you would have to do it in chunks of 64 KB of data. Working with data that didn't fit into these 64 KB chunks was a real pain and real slow.

The move to 32 bits allowed up to 4 GB of RAM to be addressed. This also brought the move to a flat memory model, which basically meant no more dealing with segments and 64 KB chunks of RAM. All of the physical memory can be addressed and this brought a major speed increase.

At present, the move to 64 bits doesn't bring such a stark difference because we are no where near reaching the 4 GB limit, especially on home computers. However 32 bit servers with more than 4 GB RAM(think Xeon with PAE) and these use the dreaded segmented memory model of old 16 bit computers. Only difference is instead of 64 KB chunks, we get 4 GB chunks (or more commonly 2 GB, depending on implementation). These servers will see a considerable benefit from moving to 64 bits because they can get rid of this horrible segmented memory model.
 
And here is another "interesting" one:
http://www.popularmechanics.com/technology/computers/2004/4/desktop_brawl/print.phtml

A piece from there:
"Not being able to run SPEC tests, we turned to BLAST and HMMer, which are DNA and genome-sequence matching tests, as well as to Bibble, a batch image-processing application. The problem is that these tests do not run on Windows XP. In frustration, after running the SPEC tests on the HP xw6000 workstation, we installed Linux on the HP, which allowed us to run the new tests. And we were surprised. The G5 was 59.5 percent faster than the HP at processing 85 high-resolution color photographs totaling 684.6MB of data. In the HMMer tests (61.3MB of data), Apple was 67 percent faster than the PC and under BLAST (32.8MB), Apple was 85.9 percent faster. These results are in line with those now published on Apple's Web site."

Some VERY serious and heavy apps that show how easily a G5 can kill any P4/XEON based computers...

Then again those same P4/XEON can easily kill the G5 in Doom3! :p Oh, I forgot... Doom3 isn't even out for the Mac :rolleyes:
 
You must log in or register to reply here.
Back
Top