Effect of doubling clock frequency on computer performance

Question

If we double the clock frequency of a CPU, does that translate to a doubling of the CPU performance? Assuming that the number of instructions and CPI are constant, we have an inverse relationship between the clock frequency and computer performance. Thus a doubling of the clock frequency will half the computer performance. Is this correct?

Answer 1

Yes, but.

Maximum clock frequency is determined by hardware physical constraints like signal propagation time, how fast the transistors switch, etc. So your hypothesis "doubling clock frequency would double performance" is missing critical fine print "as long as it is below the maximum frequency the hardware supports, and the new frequency does not require reconfiguration".

Also, different types of hardware work best at different frequency, for example if you want a faster clock, at some point you'll need more pipeline stages and fancier design, so the hardware for the slow clock frequency is not the same as the hardware for the fast clock frequency and they are not comparable in a simple way.

For example, say your silicon process can make an ALU that needs 2ns to add two integers (forget about all the rest of processor business for now like instruction decoding etc). Without pipelining you can run it at 500MHz (2ns cycle) but if you split it into 4 pipeline stages then maybe you can run it at 2GHz (0.5ns cycle), it will do an operation in 4 cycles, the operation will still take 2ns to complete (neglecting pipeline efficiency for the sake of simplicity) but it can do 4 operations in the pipeline, so it has the same 2ns latency, but 4x higher throughput than the non-pipelined version.

However if you take this 2GHz 4-stage hardware and run it at 500MHz instead of 2GHz, it will have the same throughput than the non-pipelined one, BUT it will have 4x higher latency so it will be a lot slower!... Hardware that runs at high clock frequency, with long pipelines, will have more latency at low frequency than simpler hardware with less pipeline stages that runs fine at low frequency. Say if you took a Pentium-4 and ran it at 10MHz, would it be faster than a 50c Cortex-M0 at 10MHz? That's hard to say because the P4 has a huge pipeline so it reacts to unexpected events like branch misprediction with quite a lot of inertia, whereas the Cortex-M0 doesn't care...

A simpler way to phrase it would be "would halving the frequency make it twice as slow?" because that won't cause problems with maximum clock frequency, and it also makes more sense, since using lower frequency clock is a very common way to trade power vs speed.

If the entire system runs on the same clock, then its performance will be proportional to clock speed. This would be the case in a simple microcontroller for example. In this case halving the frequency will make it twice as slow on the same hardware.

However, in a more complex system like a PC, SoC, or larger microcontroller, different parts of the system will most likely use different clocks. In a PC, there are different clock frequencies for CPU cores, RAM, chipset, various buses, sometimes caches, etc. So "doubling clock frequency" doesn't mean much, although you could say "if all the clocks in the system were scaled by the same factor then performance would scale proportional to that too."

Of course this assumes the processor is not waiting on something that doesn't depend on this clock frequency, for example network data, IO, I2C communication, waiting on an ADC to deliver data, etc. If some part of processing is dominated by timings that don't depend on clock frequency, for example latency due to signal propagation in cables or traces, then clock frequency will influence throughput but not latency. That's what happens with DDR SDRAM timings for example. If you crank up the frequency of your RAM stick you also have to add a bit more latency/wait cycles because the actual time the chip needs to access the data doesn't depend on clock.

That's why I talked about reconfiguration in the first paragraph. If you use half the clock frequency for your RAM, then it will be twice as slow. However, if you reconfigure the latency settings to match the new frequency, then you can keep the same latency (in nanoseconds) which means less cycles of the lower frequency clock. So your RAM will have lower throughput (since clock controls data transfer speed) but latency won't degrade that much. So it will be twice as slow for large sequential access but not for random access. Subtle, huh?

Answer 2

If we assume the CPU can handle doubling it's clock frequency and everything in the CPU will now work at twice the speed, the CPU will be twice as fast. So if the CPU calculates A+B from it's internal cache memory it will do this twice as fast

BUT that does not take into account the speed of other parts that make up a computer. The CPU might be twice as fast, but the RAM, HDD etc will not. Even RAM is slow compaired to the CPU (and HDDs are at glacial speeds), which means if the CPU get data from the RAM it will have to wait on the RAM. Let's say the CPU at the first speed has to wait 1 ms, which could be 1000 clock cycles, now with the doubling of the CPU clock the CPU has to wait 1 ms, which would be 2000 clock cycles for the cpu.

As you can imagine really hurts your new found performance boost from doubling the CPU clock frequency. Say if you copy some data from the HDD to RAM, the CPU part will be such a tiny part of the time this takes you wouldn't notice anything by doubling the CPU speed. But if you time some program that can run entirely in the cache of the CPU you would see it running twice as fast.

So it really depends on the program you are running on the computer how much of a performance boost you would see by doubling the CPU clock frequency. But it is safe to assume it is less than 2x.

Answer 3

You will have to define what "performance" means. The other answers here do a good job of defining performance in terms of raw compute potential versus the limits of the operating speed of other components in a system. However these days you have to measure performance in several other ways as well. I will describe two of these here.

1. An important performance measurement is raw compute potential per watt of energy consumed. This may have to include more than just the CPU in the equation because all the components of the system are energy consumers. This measure translates directly to operating cost that comes in two parts - initial system cost and recurring energy cost.

2. A second performance measure is based upon the compute task that needs to be done. We can define this compute task as "the workload" that must be executed. The workload requirements will be very specific to each defined task but may very well be dependent upon factors that go out into the world (maybe even the universe in the extreme case). The important measure here is "how much system cost do I need for my workload?" Raw compute potential may have little to do with getting the job done.