Macintosh/powerpc processor speed question..

[Gangularis]

I'm not sure if any of you recall, but back when the mac was using the PowerPC processor it always advertised a much slower processor speed in comparison to regular PC processors of the time, and yet it was usually considered much more powerful than a PC processor of equal operating frequency..

Is there anyone that can explain that more to me, or point me to a good article about it? I never fully understood it.

[Skwinty]

Might have had something to do with the PowerPC having a Reduced Instruction Set Chip (RISC) as opposed to the PC processor chip which had a more numerous and complex instruction set. (CISC)

[aggle-rithm]

Might have had something to do with the PowerPC having a Reduced Instruction Set Chip (RISC) as opposed to the PC processor chip which had a more numerous and complex instruction set. (CISC)

More specifically...the power of the RISC architecture is that all instructions are the same size. Once they are the same size, you have the ability to pipeline instructions. There is a four-step process in executing an instruction, and with pipelining you can have four instructions being executed at the same time, each in a different step. The CISC requires each instruction to wait for the previous one to finish all four steps before it can begin to execute.

The RISC has been losing ground to the CISC over the years because Intel has been able to implement some pipelining in its architecture as well. It also has an advantage because it is simpler to write machine code for a CISC processor, because it takes care of precedence issues. When writing a compiler for a RISC processor, the programmer must always be aware of which instructions must be executed first.

[Skwinty]

Thats right, just couldn't recall the details off the top of my head.
Thanks.

[Gangularis]

I'm just wondering how this relates to the "frequency" that the chip operates at? Although I consider myself a techie, I don't fully understand the mechanics of a CPU. I took intro to computer science twice, while at a university, so I have some idea about how circuit building and gates work, but I don't understand the concept of frequency and how that relates to processors.

[aggle-rithm]

I'm just wondering how this relates to the "frequency" that the chip operates at? Although I consider myself a techie, I don't fully understand the mechanics of a CPU. I took intro to computer science twice, while at a university, so I have some idea about how circuit building and gates work, but I don't understand the concept of frequency and how that relates to processors.

IIRC, at each tick of the internal clock, a RISC processor is working on four instructions, while a CISC processor only one. Although the RISC processor does less with each instruction, it completes them four times faster. This translates to more work per cycle, but it's difficult to measure exactly how much more. A lot depends on how the code is optimized.

[BenBurch]

Basically correct. Except humans do not write machine code much any more, and those of us who do only do it rarely.

One pipelined processor architecture I wish had a modern representative is the Denelcor HEP. http://en.wikipedia.org/wiki/Heterogeneous_Element_Processor

Their implementation was imperfect, but the concept was astounding.

[GreNME]

Another thing to keep in mind was that by the early 2000's, the arguments claiming RISC processors were better performers happened to be a useless gesture-- the x86 chips on the market by then were using a processor that was basically a RISC(-like) chip with the x86 instructions running over top of it. This was developed, if I recall, by AMD for their processors, but since Intel and AMD license technologies back and forth to each other almost all of the chips on the market for personal computers were running RISC at their core. At that point the only debate left was academic in terms of chip instructions and other minor infrastructure differences.

[W.D.Clinger]

[RISC] also has an advantage because it is simpler to write machine code for a CISC processor, because it takes care of precedence issues. When writing a compiler for a RISC processor, the programmer must always be aware of which instructions must be executed first.
Not sure what you mean by precedence issues, but the PowerPC always presented the illusion of sequential execution despite its concurrent out-of-order and speculative execution. That would have been far more difficult for a CISC instruction set.

Current implementations of x86 family processors dynamically translate the CISC instruction set to an internal, proprietary RISC-like instruction set, which provides some of the benefits associated with RISC execution.

Basically correct. Except humans do not write machine code much any more, and those of us who do only do it rarely.
We write machine code indirectly by employing compilers to generate the machine code from our programs. Although CISC instruction sets are sometimes touted as compiler-friendly, generating machine code for RISC architectures is easier in many respects, especially for sophisticated compilers.

[aggle-rithm]

Not sure what you mean by precedence issues, but the PowerPC always presented the illusion of sequential execution despite its concurrent out-of-order and speculative execution. That would have been far more difficult for a CISC instruction set.

After further reflection, I realize what I meant was: The machine code programmer (the person writing either the compiler or the assembler) needed to be aware of dependencies, so that if an instructions was dependent on the completion of another instruction, they couldn't both be in the pipe at the same time.


We write machine code indirectly by employing compilers to generate the machine code from our programs.

Right...I was referring to the compiler programmers who translate high-level languages to assembly. The machine code is written by the assembler.

[BenBurch]

... so that if an instructions was dependent on the completion of another instruction, they couldn't both be in the pipe at the same time. ...

Which is the issue the HEP architecture addressed.

[Ziggurat]

In regards to PowerPC vs. x86, chips, I'm wondering how much of the difference was floating-point arithmetic performance. Back in the late 90's I had a Cyrix 686 chip in my machine. Clock for clock, it was considerably faster than a Pentium (though typically clocked somewhat slower) on integer operations. But for floating point operations, if was much slower. That didn't show up when doing word processing or web surfing, but it was very visible in the new (at the time) 3D games. That wasn't an instruction set difference, that was purely a processor-specific difference. Intel designed the Pentium with floating point performance as a priority. Cyrix had not (neither had AMD at the time, though they remedied that with the Athlon line). I've never owned an apple so I didn't pay close attention to them, but I wouldn't be surprised if something similar was going on: PowerPC chips might have been faster at integer operations but slower at floating point. Not really a RISC vs. CISC issue, but an issue of where to allocate chip resources.

[aggle-rithm]

In regards to PowerPC vs. x86, chips, I'm wondering how much of the difference was floating-point arithmetic performance. Back in the late 90's I had a Cyrix 686 chip in my machine. Clock for clock, it was considerably faster than a Pentium (though typically clocked somewhat slower) on integer operations. But for floating point operations, if was much slower. That didn't show up when doing word processing or web surfing, but it was very visible in the new (at the time) 3D games. That wasn't an instruction set difference, that was purely a processor-specific difference. Intel designed the Pentium with floating point performance as a priority. Cyrix had not (neither had AMD at the time, though they remedied that with the Athlon line). I've never owned an apple so I didn't pay close attention to them, but I wouldn't be surprised if something similar was going on: PowerPC chips might have been faster at integer operations but slower at floating point. Not really a RISC vs. CISC issue, but an issue of where to allocate chip resources.

I had a 486 where the floating-point unit was a separate chip.

Ah, memories...

[elgarak]

I had a 486 where the floating-point unit was a separate chip.

Ah, memories...
From what I remember the 486 had the FPU build in, but the FPU did not work on some batches. Instead of throwing the bad batches out, Intel sold them cheaper as "486SX". :D

They then realized that a lot of people do not actually need the FPU, so Intel started to intentionally make SX processors, with the FPU missing.

[W.D.Clinger]

PowerPC chips might have been faster at integer operations but slower at floating point. Not really a RISC vs. CISC issue, but an issue of where to allocate chip resources.
Most of the PowerPC chips had good floating-point performance.

The PowerPC 604 and 604e could execute any sequence of floating point operations (except division) at a sustained rate of 1 operation per clock cycle.

According to D. J. Bernstein (http://cr.yp.to/hardware/ppc.html), the G4 processors could execute 3 double precision floating point operations in 4 cycles, or 4 operations in 5 cycles.

In a floating-point-intensive loop, the integer and branching instructions were usually cost-free because they could be executed concurrently with the floating point operations. If loads and stores were the bottleneck, you'd run at the speed of the memory system.

[Ziggurat]

Most of the PowerPC chips had good floating-point performance.

The PowerPC 604 and 604e could execute any sequence of floating point operations (except division) at a sustained rate of 1 operation per clock cycle.

According to D. J. Bernstein (http://cr.yp.to/hardware/ppc.html), the G4 processors could execute 3 double precision floating point operations in 4 cycles, or 4 operations in 5 cycles.

That's probably comparable to pentiums, but the PII was capable of doing two floating point operations per cycle (an add/subtract and a multiply/divide). And it came out a little before the "G3" processors (really PowerPC 740 and 750 - the G3 and G4 monikers being Apple branding and not the actual processor).

[Nick Bogaerts]

Intel designed the Pentium with floating point performance as a priority.

Rather than, say, accuracy.

[W.D.Clinger]

That's probably comparable to pentiums, but the PII was capable of doing two floating point operations per cycle (an add/subtract and a multiply/divide).
The PowerPC could do fused multiply/add or multiply/subtract via its fmadd, fmsub, fnmadd, and fnmsub instructions. I never even tried to understand instruction-level timing for the PII (it's complicated), so I can't compare the two in detail.

And it came out a little before the "G3" processors (really PowerPC 740 and 750 - the G3 and G4 monikers being Apple branding and not the actual processor).
BYTEmark benchmark comparisons from that era are here:
http://www.macspeedzone.com/archive/4.0/WinvsMacbytemark.html
That's a pro-Macintosh site, for whatever difference that makes.

According to that set of floating point benchmarks, a 200 MHz PowerPC 604e was slower than a 300 MHz Pentium II, but a 350 MHz 604e was faster than a 400 MHz Pentium II.

[BenBurch]

Rather than, say, accuracy.

Zing!

[nota]

geekbench results offer a direct number for intel vs PPC chips
not real speed but a clue

[aggle-rithm]

Rather than, say, accuracy.

The way floating-point is represented is pure voodoo.

I prefer working with integers and then sliding in a decimal point at the last minute.

[asmodean]

After further reflection, I realize what I meant was: The machine code programmer (the person writing either the compiler or the assembler) needed to be aware of dependencies, so that if an instructions was dependent on the completion of another instruction, they couldn't both be in the pipe at the same time

Ah, load delay slots. Once instruction X is done with the exec stage of the pipe, the instruction X+1 is using the same registers (for instance) that X just wrote to, but the register file wont be updated for another stage. MIPS also had that as I recall. First time I saw a function that poped the stack AFTER returning from the routine I was alittle bit confused to be honest. :)

Not all RISCs have this though, as I recall it, the ARM stalls the pipeline if it detects a situation like this.

[jeremyp]

More specifically...the power of the RISC architecture is that all instructions are the same size. Once they are the same size, you have the ability to pipeline instructions. There is a four-step process in executing an instruction, and with pipelining you can have four instructions being executed at the same time, each in a different step. The CISC requires each instruction to wait for the previous one to finish all four steps before it can begin to execute.
This is completely untrue. Pipelining does not rely and never has relied on instruction size. It's also been around for longer than the idea of RISC.

Also the assertion that the power of RISC is in the instruction size being constant is manifestly false. There are CISC machines with constant sized instructions too.

The point of RISC is that the instruction decoding logic is much simpler meaning that each instruction takes fewer clock cycles to execute and the chip real estate saved can be used for more registers and fast memory cache.

The RISC has been losing ground to the CISC over the years because Intel has been able to implement some pipelining in its architecture as well.
RISC has not lost ground to CISC. The most popular processor architecture in the World (ARM) is RISC.

It also has an advantage because it is simpler to write machine code for a CISC processor, because it takes care of precedence issues.
Almost nobody writes machine code anymore.