Processor architecture, measured — arm64 and x8664, and no winner

Processor architecture, measured — arm64 and x86_64, and no winner

SixPanel publishes a separate signed release per processor architecture, and both x86_64 (amd64) and arm64 (aarch64) are live. This page is the round that established there is no speed reason to prefer either one.

It is a negative result, and it is the useful kind: it turns a technical question into a commercial one. If neither architecture is faster, then price and availability decide, and arm64 is frequently the cheaper of the two for the same shape.

The short answer

Take whichever your provider gives you the better deal on. Both install with the same one-line command; the installer works out which build your server needs.

arm64 was verified end to end on an AWS t4g.medium (Graviton, Neoverse-N1): the install completed, the panel ran, and the entry page was reachable.

The boxes

Same shape on every machine, so a difference here is the machine rather than the software: 2 cores, ~3.8 GB RAM, Ubuntu 26.04, PHP 8.5.4, MariaDB 11.8.6.

Processor — seconds for a fixed job, median of 5

Lower is better.

Three workloads, two directions, no single winner. ARM is the fastest of the three on plain PHP integer work — 0.61 s against Intel's 0.85 s, a 28 % lead — and the slowest on sha256, 0.20 s against 0.11 s. The processor does advertise the sha2 extension, so that row is a build or library difference rather than missing hardware. Node goes the other way and favours Intel.

Which one leads depends entirely on what the box spends its time doing, and no ratio taken from this table describes a whole application. That is why the site makes no "arm64 is faster" claim in either direction.

Memory and disk

The disk row is the one that settles a buying decision, and it is identical on all three. About 125 MB/s and roughly 330 synced writes per second, within 6 % — that is the storage tier's own baseline, not a property of the processor. For a shop it is the ceiling that matters most, because a database waits on synced writes, and choosing between these instance types does not move it.

What this round does not claim

• That either architecture is faster. Two of three workloads went one way and one the other. A single winner cannot be read out of that.
• That the AMD box is the slowest. It was being throttled throughout, repeatably — 53 to 60 steal jiffies during every one of three measurement runs, against 1 to 4 on the Intel and ARM boxes. Its figures are a floor, not a capability. This is what burstable instances do when their credit runs low, and it is why a 6 % gap between two of these boxes means nothing.
• Anything about a whole shop's speed. These are processor and disk micro-benchmarks. The application rounds are elsewhere: the aaPanel benchmark is the whole-application measurement.
• Anything about servers larger than these. One shape was measured.

Three wrong readings, caught on the way

Every measurement carries a steal-time delta read from /proc/stat around it, because these are burstable instances and a throttled sample looks exactly like a slow processor. Three disk readings were wrong before they were right, and each produced a plausible-looking number rather than an error:

1. dd writes its statistics to stderr — the same stream the timing tool uses. The median then picked one of dd's own lines, reporting "256.000 seconds" for a 256 MB write.
2. Moving the redirect silenced the timer rather than dd, because the shell applied it to the whole command, so every figure came back 0.00. dd needs its own subshell.
3. The write target was /tmp, which is tmpfs on all of these boxes — so the disk rows measured RAM and reported 200,000 synced writes per second, which no disk does. The target has to sit on the root filesystem, where the database actually lives.

A number that looks reasonable is not evidence that the measurement was correct. All three of these passed inspection until the figure was checked against what the hardware could physically do.

Related

How we measure is the method and where the raw data lives. The OS and stack round is the six-axis version-swap round, which reached the same kind of conclusion about software versions. For the decision rather than the evidence: which operating system covers the architecture choice alongside the release choice.