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

> Source: https://www.allsweb.com/measurements/cpu-architecture
> Markdown for agents: https://www.allsweb.com/measurements/cpu-architecture.md
> Publisher: AllsWeb (www.allsweb.com)

Part of: Measurements

# 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.

**Measured 28 August 2026** on three AWS instances of the same shape — `t3.medium` (Intel), `t3a.medium` (AMD) and `t4g.medium` (Graviton) — each 2 cores, about 3.8 GB, Ubuntu 26.04, PHP 8.5.4, MariaDB 11.8.6.

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.

| | x86_64 (amd64) | arm64 (aarch64) |
|---|---|---|
| **Native SixPanel** | published | published |
| SixPanel Docker (retired 29 Aug 2026) | was published | never published |

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.**

| | Intel `t3.medium` | AMD `t3a.medium` | ARM `t4g.medium` |
|---|---|---|---|
| CPU | Xeon Platinum 8259CL | EPYC 7571 | Neoverse-N1 |
| Architecture | x86_64 | x86_64 | aarch64 |

## Processor — seconds for a fixed job, median of 5

Lower is better.

| Workload | Intel | AMD | ARM |
|---|---|---|---|
| PHP, 40M integer operations | 0.85 | 0.92 | **0.61** |
| PHP, 120k sha256 | 0.12 | **0.11** | 0.20 |
| Node, 400M integer operations | **1.31** | 1.77 | 1.52 |

**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

| | Intel | AMD | ARM |
|---|---|---|---|
| Memory read | 17.0 GB/s | 10.1 GB/s | 11.6 GB/s |
| Sequential write | 125 MB/s | 126 MB/s | 125 MB/s |
| Synced 4k writes | 336 IOPS | 316 IOPS | 331 IOPS |

**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](https://www.allsweb.com/measurements/against-aapanel) 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](https://www.allsweb.com/measurements/how-we-measure) is the method and where the raw data lives. [The OS and stack round](https://www.allsweb.com/measurements/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](/compare/operating-systems) covers the architecture choice alongside the release choice.