The Clock Is a Variable

A modern core continuously selects an operating point — a frequency and voltage pair — from a range the part supports. The selection is made by hardware and firmware in response to conditions that change on a millisecond timescale: how many cores are active, current power draw against the package limit, temperature against the thermal limit, and the governor policy the operating system has requested.

Two consequences follow immediately. First, the same code can take measurably different wall-clock times on the same machine depending on what else was happening, how warm the chip already was, and how long ago it was last idle. Second, cycles and time are not interchangeable units. A run that consumed the same number of cycles as another can take longer if it spent them at a lower frequency, which is a routine source of confusion when comparing cycle counts to stopwatch results.

The single most important practical instance is that a core running alone can typically clock higher than the same core when all its siblings are busy, because power and thermal budget are shared across the package. This means a single-threaded benchmark and the same code running on every core are measuring the chip in two genuinely different states, and comparing them without noting that is comparing two machines.

The least intuitive entry in that table deserves its own treatment. Executing wide vector instructions activates a great deal more silicon per cycle than scalar code does, and that draws more power. On several designs the response is to reduce the operating frequency while such code is executing, so that the package stays within its power envelope.

The practical effect is that a vectorized loop measured in cycles can show an impressive speedup that partly evaporates when measured in seconds, because those cycles were shorter-lived. Worse, on some implementations the frequency reduction persists for a while after the vector code finishes, so an unrelated scalar section running immediately afterwards is penalised by code it did not execute.

None of this makes vectorization a bad idea — it usually remains a substantial net win, and SIMD: One Instruction, Many Elements explains why. What it does mean is that the wall-clock measurement is the honest one, that cycle-count comparisons across differently-vectorized code should be treated with suspicion, and that the magnitude of the effect is strongly design-dependent, having changed considerably across generations even within a single vendor.

The defence is a small set of habits. Report wall-clock time as the primary result, because it is what a user experiences and it already includes the frequency effect. Report cycles as the diagnostic, because cycles are what the counters explain. When the two disagree, the difference is frequency, and that is information rather than an error.

For any comparison, run long enough to reach a steady operating point rather than measuring the boost window, and state whether the run was single-threaded or fully loaded, since those are different machine states. Where the environment permits it, pinning the frequency governor to a fixed performance state removes the variable entirely and makes cycle counts directly comparable — at the cost of no longer measuring the machine as users will actually experience it.

On cloud instances this is largely out of reach: frequency policy belongs to the host, the physical core may be shared, and the neighbouring tenants influence thermal and power state in ways you cannot observe. That is a genuine limitation rather than a solvable problem, and the correct response is to measure more repetitions, report distributions rather than single numbers, and treat modest differences with appropriate scepticism.