ARM reaches the server room

For about fifteen years, "server" has meant x86-64 so totally that it stopped being a decision anyone made.

That is ending, and the instruction set is the least interesting part of it. What matters is what a monoculture hides.

What a monoculture costs you¶

Software that has only ever been built on one architecture collects assumptions it doesn't know it's carrying:

• Memory ordering. x86-64 is strongly ordered; ARM is weakly ordered. Concurrent code that is subtly wrong (a missing barrier, a non-atomic read of something assumed atomic) works by accident on x86 and fails intermittently on ARM. The bugs were always there. The architecture change makes them visible.
• Unaligned access. Tolerated on x86, historically not on ARM; AArch64 tolerates most of it now, with device memory and atomics still trapping.
• char signedness. Plain char is implementation-defined, and the common toolchains settled on signed for x86 and unsigned for ARM. Not an architectural rule, and -fsigned-char will override it, but it is the default you meet. A twenty-year-old C idiom that happened to work quietly stops working.
• Build toolchains. The deepest one. Every vendored binary, every curl | sh installer, every container image with no arm64 tag.

The first three are compiler and code problems and you can mostly fix them. The fourth governs the timeline, because it's a social problem spread across thousands of projects, and you can't patch a social problem.

Why a Pi was a useful filter years early¶

We ran a Raspberry Pi cluster in 2016, and the compute was neither here nor there. What it did was tell us straight away which parts of a stack were x86-only, years before that became anyone's commercial problem.

Anything that wouldn't build was something we'd have to fix eventually. It cost us almost nothing to find that out early, which is about the best return you get on a shelf of forty-pound computers.

What the shift unlocks¶

Not performance, to begin with. The first credible server ARM parts are competitive rather than dominant on raw throughput.

What changes is the design space. An organisation that can specify its own silicon can make trades a general-purpose vendor can't: more cores at lower clocks, memory bandwidth over single-thread latency, accelerators for the workload it runs rather than the workload in the benchmark suite.

The benchmark headlines matter less than what follows once the architecture is a choice.

Performance per watt becomes the number people buy on. A rack is limited by the power and cooling you can get into the building, not by the number of U. Once two architectures compete on work-per-joule, the cost of a colocation cabinet and the cost of a small on-premises room both fall in a way they haven't since the Xeon took over. A business that could not previously afford to run its own compute gets a credible option that is not a hyperscaler invoice. That is the benefit we care about most, because it widens who can own infrastructure at all.

Developer hardware and production hardware converge. An engineer on an ARM laptop building for an ARM server is testing the thing they ship. The whole category of "works on my machine, breaks in production because the compiler made a different choice about a struct layout" shrinks. That bug class is a tax on every team that has ever cross-compiled; take it away and you get the time back.

Portability becomes a tested property again rather than a claim in a README. Every project that gets a second build target gains a permanent regression test for undefined behaviour. The cleanup is already happening in public, in CI configs, and everything that comes after this benefits whether it knows it or not. RISC-V is the obvious next candidate to collect that benefit; it arrives into a far friendlier world than ARM did, because somebody else already paid for the port.

That choice only exists if you can buy the silicon.

The companies doing the interesting ARM server work at this scale are mostly designing parts for themselves. The design space opens up for whoever can commission a run at a leading foundry, pay for the IP licences and absorb a multi-year programme before the first machine boots. That is a very short list, and nothing about ARM's instruction set changes the list.

So the question to ask of any ARM server announcement is not how fast the chip is. It is: can I buy one, in a quantity I want, and put it in a rack I control? For a lot of the best silicon in this generation, the answer is no. It exists only as an instance type. You rent the performance-per-watt win from the operator who commissioned the part, and the efficiency gain lands on their margin rather than your bill. The allocation queue is the chokepoint, not the architecture.

That is a worse outcome than the x86 monoculture it replaces, in one specific respect. A commodity x86 server was something anyone could buy from several vendors at a published price. "Available only as a managed instance" is not commodity. If the end of the monoculture produces three architectures that are each a single operator's private advantage, we have swapped one lock-in for a better-performing one.

The open side of this transition needs general-purpose ARM boards that a mid-sized business can order ten of, and a toolchain nobody has to ask permission to use. The toolchain is in good shape. The procurable hardware is the half that is losing, and it is the half worth pushing on.