Performance Per Watt
Energy, not time, is the constraint that actually binds on phones, on laptops and across datacentres. The configuration that finishes soonest is frequently not the one that uses least energy, and the relationship between the two is non-linear enough that "run slower to save power" is often exactly wrong.
Software view, hardware view
The gap between what you wrote and what the machine does is where this whole domain lives.
Power and performance are not linearly related
Raising frequency requires raising voltage, and dynamic power scales roughly with voltage squared times frequency. The practical consequence is that the last increment of clock speed is disproportionately expensive: pushing a core near the top of its range can cost a large fraction of additional power for a modest fraction of additional performance. This is the physical reason boost is time-limited rather than permanent.
Read in reverse, the same relationship says that running somewhat *below* peak is often dramatically more efficient — a small performance sacrifice for a large power saving. This is why datacentre operators frequently run parts below their maximum rating, and why efficiency-focused core designs target a lower operating point rather than simply being smaller.
The complication is that a system draws power even when doing nothing useful. Displays, radios, memory refresh, background activity and the platform itself all consume energy for as long as the system is awake. So total energy for a task is not simply power multiplied by compute time — it is the compute energy plus everything else the system spent while the task was outstanding.
| Configuration | Time to finish | Power draw | Total energy | Best for |
|---|---|---|---|---|
| Peak frequency | Shortest | Highest, superlinear in clock | Often not lowest | Latency-sensitive interactive work |
| Slightly below peak | Marginally longer | Substantially lower | Frequently the lowest | Throughput work, datacentre fleets |
| Well below peak | Much longer | Low | Rises again — fixed platform costs dominate | Rarely optimal for a fixed workload |
| Efficiency-focused core | Longer | Much lower | Lowest for suitable work | Background and sustained low-priority tasks |
| Specialised accelerator | Shortest for its narrow workload | Moderate | Lowest by a wide margin when applicable | See The Specialization Trade-off |
Race to idle, and when it stops working
The fixed platform cost is what produces the race to idle strategy: finish the work as fast as possible so the system can enter a deep low-power state sooner. If the platform draws significant power merely being awake, and if the deep sleep state is genuinely low-power, then a short burst at high frequency followed by a long sleep can use less total energy than a long stretch at low frequency, even though the burst itself was less efficient per unit of work.
Whether it actually wins depends on the balance between three quantities: how superlinear the power curve is near the top, how large the fixed awake cost is, and how deep and how quickly reachable the sleep state is. On a mobile device with an expensive display and effective sleep states, racing to idle frequently wins. On a server that never sleeps because requests keep arriving, there is no idle to race to, and running near the efficiency sweet spot wins instead.
That distinction — a device that can sleep versus a machine that never does — is the one that decides the strategy, and it explains why mobile and datacentre engineering reach opposite conclusions from the same physics. Both are correct for their setting, which is why "run slower to save power" is good advice in exactly one of the two.
1# Low frequency for a long interval.2compute_energy = low_power x long_time3platform_energy = awake_cost x long_time # paid the whole time4total = both, and the platform term is large5 6# Sensible on a server that will not sleep anyway.1# High frequency briefly, then a deep low-power state.2compute_energy = high_power x short_time # less efficient per unit work3platform_energy = awake_cost x short_time # much smaller term4 + sleep_cost x remaining # near zero5total = frequently lower overall6 7# Sensible on a phone or laptop with effective sleep states.The same physics gives opposite answers depending on whether the platform can actually reach a deep idle state. The compute term favours running slower; the platform term favours finishing sooner. Which dominates is a property of the device, not of the code.
What a programmer can actually change
Most of the levers here belong to firmware and the operating system, and a programmer who tries to manage frequency directly is usually working against a controller with far better information. The lever that genuinely belongs to software is the amount of work requested, and it is a large one: every instruction not executed, every cache line not fetched and every page not touched is energy not spent.
Data movement deserves particular attention, because moving data costs meaningfully more energy than computing on it, and the gap widens the further the data travels. Fetching from DRAM costs far more energy than reading a register, and crossing to another socket or another machine costs more again. This gives the entire memory-hierarchy discipline a second justification: the layouts and access patterns that make a program fast for the reasons in The Memory Hierarchy also make it cheaper to run.
At fleet scale the same logic reappears as cost. Power is both the operating expense and the hard physical limit on how much compute fits in a building, so efficiency work translates directly into capacity that did not have to be bought. That is the connection between this lesson and Cost per Request: The Other Performance Metric — the same optimisation shows up on the electricity bill and in the capacity plan.
- Doing less work is the software lever. Everything else belongs to firmware and the OS.
- Moving data costs more energy than computing on it, and the cost rises with distance.
- Cache-friendly layouts are also energy-friendly — one optimisation, two benefits.
- Idle efficiency matters as much as busy efficiency on anything that sleeps.
- At fleet scale, power is the capacity limit, not just the bill.
Key points
- Dynamic power scales roughly with voltage squared times frequency, so the last increment of clock speed is disproportionately expensive.
- Total energy includes the fixed cost of keeping the platform awake, not just the compute itself.
- Racing to idle wins where a deep sleep state is reachable; running at the efficiency sweet spot wins where the machine never sleeps.
- The main software lever is doing less work, particularly moving less data — data movement costs more energy than arithmetic.
- At datacentre scale power is simultaneously the operating cost and the physical limit on deployable compute.
Follow the mechanism
The path through the machine, hop by hop — and the conclusions it invites that are wrong.
- 1Frequency → voltage: higher clocks require higher voltage to switch reliably.
- 2Voltage → power: dynamic power rises roughly with the square of voltage times frequency, so the relationship is steeply superlinear.
- 3Compute time → platform energy: while the task is outstanding the whole system stays awake and draws its fixed cost.
- 4Task completion → sleep: finishing sooner allows a deep low-power state, eliminating the fixed cost for the remainder.
- 5Data movement → energy: each level further from the core costs substantially more energy per byte moved.
- • Assuming lower clock always means lower total energy, ignoring the fixed cost of staying awake longer.
- • Optimising only for latency on a device where the user actually experiences battery life.
- • Treating energy as proportional to runtime, when it depends on frequency, instruction mix and data movement.
- • Ignoring idle behaviour entirely on a workload that spends most of its time waiting.
Consequences, controls and cost
- • The fastest configuration is often not the most energy-efficient one, and the gap is largest near peak frequency.
- • Battery life responds more to reducing total work and enabling sleep than to lowering the clock.
- • Datacentre capacity is bounded by power delivery and heat removal before it is bounded by floor space.
- • Memory-hierarchy optimisations reduce energy as well as time, so the two goals rarely conflict.
- • Reduce total work — fewer instructions, fewer bytes moved, fewer pages touched.
- • Improve locality: keeping data in nearer cache levels saves energy as well as cycles.
- • Allow the system to reach idle: batch background work rather than waking repeatedly.
- • Leave frequency management to firmware and the OS, which have information a program does not.
- • Measure energy directly where the platform exposes it, rather than inferring it from runtime.
- • Direct energy counters where the platform provides them, over a complete task rather than a sampled interval.
- • Energy per unit of work — per request, per frame, per element — rather than raw watts.
- • Battery drain over a realistic duty cycle, including idle periods, on mobile targets.
- • Fleet-level power draw against delivered throughput, which is the datacentre form of the same ratio.
- • Running below peak frequency saves energy at the cost of latency, which is unacceptable for interactive work.
- • Batching work to enable sleep increases latency for whatever was batched.
- • Efficiency-focused cores are slower per thread, so work scheduled onto them takes longer to complete.
Scope
§224 — what these claims are specific to.
- PLATFORM-SPECIFICIdle state depth, wake latency, fixed platform draw and available energy counters differ enormously between mobile devices, laptops and servers, and determine whether racing to idle wins at all.
- MICROARCH-SPECIFICThe shape of the frequency-to-power curve and the existence of separate efficiency-focused cores are design decisions that vary by vendor and generation.