Ubuntu's amd64v3 Question: Performance Today, Compatibility Tomorrow
Phoronix's Strix Halo numbers show what Ubuntu 26.10's experimental x86 64 v3 archive buys on modern hardware. The harder question is who gets left behind when the floor moves.
Phoronix's Strix Halo numbers show what Ubuntu 26.10's experimental x86 64 v3 archive buys on modern hardware. The harder question is who gets left behind when the floor moves.
The Phoronix benchmark review of Ubuntu 26.10's amd64v3 packages tells two stories at once. One is technical. On a Framework Desktop with Ryzen AI Max+ 395 (Strix Halo), x86-64-v3-built Ubuntu packages run measurably faster than the default amd64 archive on real workloads, including Zstd and LZ4 compression, cryptsetup and Botan, OpenSSL and GnuPG, Darktable and GEGL, GraphicsMagick, GNU Radio, GNU Octave, OpenJDK, R, POV-Ray, RawTherapee, and Python and PHP. The other is strategic. Canonical is running the same baseline experiment Red Hat Enterprise Linux 10 already committed to in 2024, and Ubuntu has not yet said whether the side repository stays a side repository or becomes the floor.
That second story is the one that matters. The benchmark shows the cost and the upside of the move in concrete code paths, but the real question is whether Ubuntu 26.10, due in late 2026, ships an official amd64v3 archive or an amd64v3 ISO, and Canonical has not answered that. The amd64v3 package repository is available today for users willing to opt in, the same way it has been quietly available in prior cycles, but no signal has emerged that 26.10 changes the official status.
The hardware baseline is the part that gets buried. x86-64-v3, also written as amd64v3, requires AVX2 and the surrounding SIMD extensions, which puts the floor at roughly Haswell-era Intel and Excavator-era AMD or newer. Anything older drops off the supported list. RHEL 10 made that trade-off official when it moved its baseline. Ubuntu is now testing whether the same floor makes sense for a distribution with a much wider consumer and prosumer footprint, and the answer will not be a single number. It will be a policy choice about who Ubuntu is for and on what hardware.
What the Strix Halo numbers actually show is that the upside is concentrated in the workloads that already call into modern SIMD paths. Compression speeds up because the libraries were rewritten to use AVX2. Cryptographic operations speed up because Botan and OpenSSL have hand-tuned vectorized paths. Image and signal processing speeds up because the toolchains reached for AVX2 years ago. The Java, R, and Python gains come from the same place: the runtimes and their numerical kernels have been vectorized for years, and the v3 packages get to keep what the default amd64 build had to leave on the table. This is not a "Linux is dying on old hardware" story. It is a "Linux distributions are deciding what modern means" story, and the cost is the older hardware on the floor.
The reader-side question is sharper. If your CPU is Haswell or newer on the Intel side, or Excavator or newer on AMD, you can opt into the amd64v3 package archive on Ubuntu 26.10 today and see most of the gain Phoronix measured on Strix Halo. If your fleet still runs pre-Haswell hardware, the question is whether to hold the line at the broader amd64 baseline or accept that those machines will fall off the supported list when the migration completes. The benchmark gives the gain in numbers. The policy choice determines who gets to keep using Ubuntu on the hardware they already own.
Red Hat already answered the policy question for RHEL 10: the v3 baseline is the official build target, and older hardware is supported through a separate channel. Canonical has not said that yet for Ubuntu, and the Phoronix review is the first public signal that the experiment is live in the 26.10 development cycle. The watch item is the release notes when 26.10 ships, and whether "amd64v3" stops being a side repository and starts being an ISO option. Until then, the benchmark is real, the trade-off is real, and the policy answer is still missing.