For most of computing's history energy was someone else's problem. You wrote software to be fast; the electricity bill turned up in a different department.
That stopped for an unglamorous reason: you cannot cool what you cannot cool. Rack density is limited by thermal capacity, so performance per watt decides how much compute fits in a building.
The chain of consequences¶
Once perf-per-watt is the binding constraint rather than raw throughput, much of the architecture follows:
- More cores at lower clocks. Dynamic power goes as capacitance times voltage squared times frequency, and holding a higher clock stable needs a higher voltage. So power rises with roughly the cube of frequency while throughput rises linearly. Two cores at half the clock therefore do the same parallel work for a fraction of the energy. That is most of why core counts went up instead of clocks.
- Efficiency cores. A core optimised for work-per-joule rather than latency.
- ARM's opening. ARM in the server room happened largely because the perf-per-watt case was strong long before the raw performance case was.
- Accelerators. Fixed-function silicon for a common operation is far more energy-efficient than general-purpose cores grinding through the same work.
The open measurement¶
The tooling to measure software energy consumption already exists: RAPL on Intel, equivalent counters elsewhere, PDU-level measurement at the rack. What does not exist is the practice. Hardly anybody puts a power figure in CI, so the numbers that circulate are modelled rather than measured, and "this is more efficient" is nearly always an argument from architecture rather than a reading. That includes most of what follows.
The measurement that would settle it is cheap: a fixed workload, a named part, RAPL and PDU readings taken together, run per commit the way a latency benchmark is. We have not instrumented our own estate for this and it is next on the list, because whoever does it first gets to make claims nobody else can check and will find savings everybody else is paying for blind.
Where the easy wins are¶
Drawn from general principles rather than our own readings, and marked as such:
- Doing less work. The biggest energy saving available to most software is algorithmic. An unnecessary poll loop costs power continuously, like a tap left running.
- Letting the CPU idle properly. Timer coalescing and avoiding short-interval wakeups let a core reach deeper C-states. A process that wakes every 10ms to check nothing prevents that.
- Right-sizing. Over-provisioned infrastructure idles, and idle isn't free.
None of those involve choosing a faster language, which is telling: the conversations that generate the most heat about efficiency are rarely the ones with the most energy in them.
What treating energy as first-class makes possible¶
Put a watt figure next to the latency figure in CI and the economics of software change shape.
Efficiency becomes a feature you can sell. A service whose power draw per request is measured and falling is cheaper to run at every scale, and where capacity is thermally capped that is capacity you did not have to buy. The team that halves its watts per transaction has doubled what fits in the building: no procurement cycle, no planning application, no grid connection queue.
Compute goes where the power is, not where the people are. Characterise workloads by energy as well as latency and it becomes practical to put the ones that tolerate delay next to intermittent, therefore cheap, generation. Batch work that follows the wind is a real architecture, and it turns a grid problem (what to do with surplus) into a compute opportunity.
Small places get to host real compute. A rack that needs eight kilowatts can go in a town with a modest supply; one that needs forty cannot. Efficient silicon is what lets a hospital, a council or a manufacturer keep its data and processing on its own premises instead of shipping both to a hyperscale region three countries away. Perf-per-watt is a sovereignty and resilience story as much as a cost one.
And the toil that disappears is capacity firefighting. The recurring emergency where a rack trips its thermal budget, or a deployment doubles a fleet's draw unnoticed for a quarter, becomes a failing build instead.
Who the savings accrue to¶
Efficiency gains do not go to the planet by default. They go to whoever owns the capacity, and historically get spent on more compute rather than less power: the building was thermally capped, you made the work cheaper, so you put more work in it. That is why a decade of remarkable perf-per-watt improvement has coincided with datacentre electricity consumption rising. Expect every efficiency claim from a large operator to be about intensity per unit of work, carefully not about total draw.
The grid connection is the chokepoint here and is barely discussed as one. In a constrained network, the right to draw tens of megawatts at a given substation is a scarce, queued, politically-allocated asset. It is secured years ahead by a handful of companies with the balance sheet to pay for options on power they do not yet need. That is a harder barrier to entry than any technology: a competitor can buy the same silicon, but not a connection allocated to somebody else until 2032. So the cheapest compute in a country is available only as rent, from whoever queued earliest, while local operators and community projects wait. Watch also for efficiency being used as the argument for why compute must consolidate: the hyperscale PUE figures are real and better than yours, and they are also the best available case for making sure you never run anything yourself.
The open side does well on the software (the kernel's power management work is public, RAPL is readable, the tooling is free) and poorly on transparency. Per-workload energy figures from the large providers are not published at a granularity that would let you compare them with your own estate, which makes the comparison unwinnable. Here at AxisOps we would rather run efficient hardware we own in a building we can point at, and publish the watts, than accept an intensity ratio from a company that picks its own numerator.
The position¶
Energy is a real engineering constraint and badly measured, which makes it fertile ground for confident claims with nothing behind them, sustainability marketing included.
The discipline is the one we apply to every other number we quote: if you can't state what you measured, on what hardware, with what tool, you're asserting. The corollary is the opportunity. Measure it, and you will know something about your own software that almost nobody knows about theirs.