- Clock rate

Inside a CPU, there are multiple units that work independently.  The unit that takes the longest to systematically alter the input bits and provide some from of output is what determines clock speed.  A unit can be broken down so that it reaches one spot of performing a function and waits for the next clock to finish.  So such lengths are shorten.  The number of times per that slowest circuit can complete in a second is our maximum clock cycle speed.  It is limited by the speed of light and thermodynamics.  Barring thermodynamics, if the CPU is clocked too fast, these function do not complete properly and cause mechanical errors.

Basically saying, a line of instruction code, such as ADD registers A and B result in A, takes multiple clock cycles to complete.

- Stages

The CPU is designed to process instruction code in four stages: Fetch, Decode, Execute, Store.  Using the prior example, the instruction code is "ADD registers A and B store in A".

The Fetch stage loads this instruction into the decode stage, and then increment the "next instruction" register.

The Decode stage takes the instruction and lines up registers A and B to the arithmetic unit with lines set to tell it to ADD and store in A.

The Execute stage pulls the data from Registers A and B, performs the add function leaving the result open to the next stage.

The Store stage takes the result and send it to register A.

Once each stage completes, the clock has to cycle before processing the next stage.  Therefore it takes multiple clock cycles to complete an instruction.

- Pipeline architecture

Before pipeline architecture, one instruction took 3 to some number of cycles to complete.  I say 3 because a few CPUs are designed to have Fetch and Decode combined.  But for a 4 stage CPU running at 1 MHz, it can complete at maximum 250,000 instructions, with the exception of the noop code, which is only 1 clock cycle and nothing is done.  Noop is intended for time sensitive synchronization.

With pipeline architecture, there is a buffer between each stage.  This allows each stage to work on an instruction independently of other instructions.  So in a 4 stage pipeline, when instruction 001 is in stage 4, 002 is in stage 3, 003 is in stage 2, and 004 just got loaded into stage 1.  On the next clock cycle, 001 is done, 002 is in stage 4, 003 in stage 3, 004 in stage 2, and 005 is loaded into stage 1.  This permits the result of 1 operation completed per cycle.

- Advance Pipelines

Remember what I said about clock speed is limited by the speed of light?  These circuits have a length of time for an electrical signal to move.  To increase clock speed, you can either shrink the transistors reducing the length, or you can shorten the circuits.  One method of shortening circuits that pipeline provided was splitting work into multiple stages.  So instead of a 4 stage pipeline, I can break it down to 8 stages and increase the clock speed by 100%.  So now we have a 4 stage 1 MHz CPU example and an 8 stage 2 MHz CPU example.  Without any bumps, the 2 MHz CPU has a maximum of 2 million instructions completed per second.

- Time for the Bad

This sounds great, which explains the massive boost of MHz speed during the age of the Pentium 4.  The Pentium 4 had a 37 stage pipeline at its worst.  Now what can go wrong?

- In Order Execution

Before the pipeline staging, one instruction could be completed at a time, some instructions require additional cycles for complex functions.  In pipeline staging, one instruction is using the ALU to calculate 5 taken to the 23rd power.  That instruction will take a few cycles to complete at this stage.  The other instructions in the pipeline are waiting on the ALU.

Answer?  Out-of-Order execution.  When entering the execution stage, if an instruction is using integer math, it uses the integer ALU.  The next cycle, a floating point instruction come up and sees the floating point ALU is not used, so it uses it, but it is waiting on the integer instruction to complete because its result is one factor in this instruction.  Again, Out-of-Order execution will allow more instructions to operate at a time by using more units simultaneously.  This mostly helps a minor problem.  This problem is practically solved.

- Conditional Branching

There are these mythical functions we use in programming.  They are "IF/THEN" statements, "FOR/NEXT" loops, "DO/WHILE" loops, "WHILE/WEND" loops, "SWITCH CASE" statements and such.  These functions perform an operation and select 1 of 2 possible instructions to perform.  If you break down the loops and switch case statement, everything is an "If... Then..." function with a Go To statement.

This translates to conditional branch instructions in the CPU.  But first, what is a branch statement?  The CPU has a "GO TO" instruction that sets the "next instruction" register to the next line of code to execute.  Looking at the 8 stage CPU at 2 MHz example, a Go To instruction would take 8 instructions, with the instruction following the Go To in the previous stage and so on.  These are the wrong instructions to be next when that Go To completes.  The result, 7 clock cycles are lost, versus 3 clock cycles for the 1 MHz CPU.  The 1 MHz CPU lost 3 microseconds of time, while the 2 MHz CPU lost 3.5 microseconds.  

Here is the MHz myth.  GO TO statements are the most important statements in the CPU and it allows us to direct things and to program AIs.  This was easily solved, although.  The Go To statement is detected and resolved from the Fetch stage.  No loss.

Now if I have this solved, why is this a MHz Myth?  Only standard branching can be handled on the fetch stage.  Conditional Branching doesn't.  Although we have branch prediction, so when the conditional branch instruction enters the fetch stage, the CPU chooses which branch to take, somehow.  Then the conditional branch has to go through all stages and if the predicted next instruction is wrong, the next instruction will be loaded into the fetch stage next cycle.

Here comes the CPU comparison of the 4 stage Wii U CPU running at 1.2 GHz versus the 14 stage PS4/XB1 1.6 GHz (somewhere around there).  One for one, the 1.6 GHz should perform 400 million more instructions per second.  Due to the Wii U's RISC nature, the condition would have been calculated by a prior instruction, leaving a true/false result ready in a primary register for the conditional branch.  If the conditional branch was right after the conditional function, then the instructions after the conditional branch instruction are predicted.  If the prediction is bad, then that is 3 clock cycles wasted (2.5 nano seconds).  Same thing for PS4/XB1 CPU, 13 cycles wasted (8.125 nano seconds).  Based on the nanoseconds lost, the Wii U will recover very quickly from bad branches.

Here is another trick the Wii U has up its sleeve.  If the "If/Then" statement had 2 lines before it that don't affect the condition, I mean having a logic condition instruction stored in a specific register and have 3 instruction that do other functions first, then the conditional branch can be resolved in the fetch stage like a regular branch, resulting in no wasted clock cycles.  This means it is easy to write code for the Wii U that doesn't cost clock cycles.

A conditional branch may only lose a few clock cycles, so why does it matter?  If/Then statements occur a lot.  For crunching numbers, like a GPU, these happen so infrequently it wouldn't matter.  For a CPU where these are the bread and bones of running the system, imagine the percentage of conditional branches ran per second.

Cores Cores Cores. PS4 uses 4 for gaming: http://www.mcvuk.com/news/read/ps4-and-xbox-one-s-amd-jaguar-cpu-examined/0116297

Meanwhile, it's reported that the Wii U has a second, 2 Core ARM CPU dedicated to the OS. This could have explained some older issues like the OS being slow to load. In saying that, interrupt handling may be on the ARM CPU. That would mean the Expresso CPU is dedicated solely to gaming. 

Now we can't just ignore the GPU, but I'm skimming through this bit for a reason: