The First Ten Seconds Lie

Switching transistors dissipates energy as heat, and the rate depends on how much of the chip is active and how fast it is clocked. The cooling solution removes heat at some finite rate. When generation exceeds removal, the die temperature rises, and when it reaches the limit the chip must reduce power — which in practice means reducing frequency, voltage, or both.

This produces the characteristic shape of a sustained workload: full speed while the thermal mass absorbs the initial excess, then a decline as the limit is approached, then a plateau at whatever frequency the cooling can sustain indefinitely. The duration of the initial phase depends on the thermal mass and the cooling capacity, which is why the same silicon behaves very differently in a thin laptop, a desktop tower and a rack server.

For anyone measuring, this is the crucial consequence: there are two performance numbers, not one. Burst performance is what the machine does before thermal equilibrium, and it is what short benchmarks measure. Sustained performance is what it does after, and it is what a production workload actually gets. Reporting the first as though it were the second is one of the most common ways a benchmark misleads, and it compounds directly with the boost effects in The Clock Is a Variable.

The same processor delivers wildly different sustained performance depending on what it is installed in. A well-cooled desktop may barely throttle at all and its burst and sustained numbers nearly coincide. A thin laptop may hold peak frequency for only seconds before settling substantially lower. A dense server may be constrained by airflow shared across many nodes, and by a datacentre inlet temperature that varies seasonally.

This makes thermal behaviour a platform property rather than a chip property, and it is why benchmark results are only comparable between machines with comparable cooling. It is also why a workload that performs well in a development environment can disappoint on deployment hardware even when the processor model is identical — the chips are the same and the boxes are not.

Two related effects complete the picture. Throttling is often not uniform across the package: some designs reduce frequency on the hottest cores first, which shows up as unexplained per-core performance asymmetry. And a chip that has been idle accumulates thermal headroom, so the first workload after a pause runs faster than the same workload thirty seconds later — which quietly ruins any benchmark harness that inserts pauses between runs.

The measurement discipline is straightforward. Run long enough for the temperature to plateau and report the steady-state figure, treating the initial burst as a separate result rather than folding it into an average. Report throughput as a time series rather than a single number, because the shape of the decline is itself diagnostic — a gradual slope is thermal, whereas a sudden step is more likely a different mechanism.

The reason that distinction matters is that thermal decline is easily confused with genuine software problems. A memory leak, a growing data structure, cache pollution accumulating over time and lock contention rising with queue depth all produce declining throughput. The way to separate them is to watch frequency alongside throughput: if frequency fell in proportion, it is thermal, and no amount of profiling the software will find anything.

What can actually be done about it is mostly not in the code. Better cooling and better airflow are the direct fixes. Spreading work across more machines instead of saturating a few keeps each further from its limit. Reducing the total work done reduces heat generated, which is the one lever that is genuinely a software decision — and it connects directly to Performance Per Watt, where doing less work is simultaneously the fastest and the coolest option.