First of all, the pipeline is just a cache of scheduled instructions. This means that a long pipeline yields high performance, only when the pipe is full of instructions that are actually usable at time of execution.

It’s hard to explain, but I’ll give it a try.

While processing instructions, it’s important to always have a next instruction ready to execute. Feeding instructions (through the pipeline) to the CPU synchronously, makes it perform at optimal speed.
Some instructions have a clear outcome as to what the next instruction will be. Hence, these instructions are “injected” in the pipe. The instructions in the pipe, are executed immediately after the CPU has finished its current “job” (instruction).
However, lots of instructions are not statically predictable. So, processing architectures use a technique, which is known under many names, let’s call it prediction.
When the next instruction to be performed, is predicted correctly, it will be executed without any loss of clock ticks. Hence, in theory, when prediction is 100% correct, every MHz counts as more speed.
Relating this back to the length of the pipeline.
When a prediction is not correct, the complete pipeline is discarded. After all, when an instruction somewhere in the pipe is not relevant anymore, the instructions that follow, aren’t either.
So, as you can guess, having a 31 instructions length pipe, will only give great results when prediction is correct. Ultimately, when prediction is 100% correct, every clock tick is optimally used. However, when a prediction is incorrect, the whole pipe has to be discarded. Off course, it has to be filled again as well.

See, for instance, the architecture of the IBM PowerPC G5 (used in the older Macs). A RISC processor with an extremely long pipeline. Anyone who has used one of these, will have noticed how some applications performed incredibly fast and some others just didn’t perform at all. It all has to do with the way they were compiled and how predictable the instructions were.

I’m leaving it at this. The only thing I have left to say, is a reaction to the following line.

Now remember that the processor cache is running at the same clock speed as the processor itself.

Only the L1 cache, L2 is slower, L3, even more!

Cheers,
Jan

The one thing I am unclear on is: Does the dual cores actually help my programs run faster or is only one of the two cores processing the data for an individual program. Also since each core isn’t independently running at 1.9Ghz a piece (making it 2.9ghz over all) then does that mean there only running at 955mhz each?