assemblycpuclockrates

In terms of instructions processed by the CPU what does the clock rate determine?


There seems to be a gap in my understanding between the CPU processing instructions and the frequency at which the quartz crystal oscillates. How exactly does the frequency of a CPU affect the speed at which a program is run? Is there a relation between the clock rate and the number of instructions processed in a given time?

Example: mov R0, #1. Assuming this instruction took one clock cycle would this take one osculation of the crystal or does it not work like that?


Solution

  • Clock rate is a very VERY poor estimate for the speed of a processor. In the olden (pre 2000s?) days, clock rate was a pretty good estimate of speed. Higher clock rate always meant better performance. These days, however, this is not true. You can have a 4GHz processor that takes 20 clock cycles to do anything, and it'll be significantly slower than a 1GHz processor that executes everything in a single clock cycle. This instruction:clock-cycle ratio stuff has become even more complex over the past few years. Now, there is L1 and L2 caches to consider. If there is a cache miss, expect an extra clock-cycle or two... usually. And then there is out-of-order execution and optimization mechanisms that can cause a divide instruction to take anywhere from less than 1(kinda) to 10 clock cycles. And there there is also hyper-threading which means that when another thread is using a component, the other thread will have to wait extra clock cycles... I could go on and on with this.

    Basically, don't. Unless you're working on simple embedded(ie, not ARM or x86) architectures clock frequency to instructions/second has little relation. Sure, two equivalent processors with one using a higher clock, should in theory yield a higher instructions/second, but it's anyone's guess as to how many more instructions per second.