Introducing architecture variants

Posted by jnsgruk 10/30/2025

Introducing architecture variants(discourse.ubuntu.com)

243 points | 145 commentspage 2

skywhopper 10/31/2025|

This sure feels like overkill that leaks massive complexity into a lot more areas than it’s needed in. For the applications that truly need sub-architecture variants, surely different packages or just some sort of meta package indirection would be better for everyone involved.

rock_artist 10/31/2025||

So if it got it right, This is mostly a way to have branches within a specific release for various levels of CPUs and their support of SIMD and other modern opcodes.

And if I have it right, The main advantage should come with package manager and open sourced software where the compiled binaries would be branched to benefit and optimize newer CPU features.

Still, this would be most noticeable mostly for apps that benefit from those features such as audio dsp as an example or as mentioned ssl and crypto.

jeffbee 10/31/2025|

I would expect compression, encryption, and codecs to have the least noticeable benefit because these already do runtime dispatch to routines suited to the CPU where they are running, regardless of the architecture level targeted at compile time.

WhyNotHugo 10/31/2025||

OTOH, you can remove the runtime dispatching logic entirely if you compile separate binaries for each architecture variant.

Especially the binaries for the newest variant, since they can entirely conditionals/branching for all older variants.

jeffbee 10/31/2025||

That's a lot of surgery. These libraries do not all share one way to do it. For example zstd will switch to static BMI2 dispatch if it was targeting Haswell or later at compile time, but other libraries don't have that property and will need defines.

zdw 10/31/2025||

Many other 3rd party software has already required x86-64-v2 or -v3 already.

I couldn't run something from NPM on a older NAS machine (HP Microserver Gen 7) recently because of this.

stabbles 10/31/2025||

Seems like this is not using glibc's hwcaps (where shared libraries were located in microarch specific subdirs).

To me hwcaps feels like a very unfortunate feature creep of glibc now. I don't see why it was ever added, given that it's hard to compile only shared libraries for a specific microarch, and it does not benefit executables. Distros seem to avoid it. All it does is causing unnecessary stat calls when running an executable.

mwhudson 11/1/2025|

No it's not using hwcaps. That would only allow optimization of code in shared libraries, would be irritating to implement in a way that didn't require touching each package that includes shared libraries and would (depending on details) waste a bunch of space on every users system. I think hwcaps would only make sense for a small number of shared libraries if at all, not a system wide thing.

smlacy 10/31/2025||

I presume the motivation is performance optimization? It would be more compelling to include some of the benefits in the announcement?

embedding-shape 10/31/2025||

They do mention it in the linked announcement, although not really highlighted, just as a quick mention:

> As a result, we’re very excited to share that in Ubuntu 25.10, some packages are available, on an opt-in basis, in their optimized form for the more modern x86-64-v3 architecture level

> Previous benchmarks we have run (where we rebuilt the entire archive for x86-64-v3 57) show that most packages show a slight (around 1%) performance improvement and some packages, mostly those that are somewhat numerical in nature, improve more than that.

pushfoo 11/1/2025||

ARM/RISC-V extensions may be another reason. If a wide-spread variant configuration exists, why not build for it? See: - RISC-V's official extensions[1] - ARM's JS-specific float-to-fixed[2]

1. https://riscv.atlassian.net/wiki/spaces/HOME/pages/16154732/... 2. https://developer.arm.com/documentation/dui0801/h/A64-Floati...

westurner 10/31/2025||

"Gentoo x86-64-v3 binary packages available" (2024) https://news.ycombinator.com/item?id=39255458

"Changes/Optimized Binaries for the AMD64 Architecture v2" (2025) https://fedoraproject.org/wiki/Changes/Optimized_Binaries_fo... :

> Note that other distributions use higher microarchitecture levels. For example RHEL 9 uses x86-64-v2 as the baseline, RHEL 10 uses x86-64-v3, and other distros provide optimized variants (OpenSUSE, Arch Linux, Ubuntu).

sluongng 10/31/2025||

Nice. This is one of the main reasons why I picked CachyOS recently. Now I can fallback to Ubuntu if CachyOS gets me stuck somewhere.

yohbho 10/31/2025|

CachyOS uses this one percent of performance gains? Since it uses every performance gain, unsurprising. But now I wonder how my laptop from 2012 did run CachyOS, they seem to switch based on hardware, not during image download and boot.

topato 10/31/2025||

correct, it just sets the repository in the pacman.conf to either cachyos, -v3, or -v4 during install time based on hardware probe

ElijahLynn 10/31/2025||

I clicked on this article expecting an M series variant for Apple hardware...

zer0zzz 10/31/2025||

There was a fat elf project to solve this problem at one point I thought.

DrNosferatu 10/31/2025|

Link?

mariusor 10/31/2025||

Maybe parent is referring to icculus' FatELF proposal from fifteen years ago? https://icculus.org/fatelf/

DrNosferatu 11/6/2025|||

Maybe Jart's APE could "host" the multiple flavors of the executable:

https://github.com/jart/cosmopolitan/blob/master/ape/specifi...

zer0zzz 11/3/2025|||

Yes I think that’s it

whalesalad 10/31/2025|

> means to better exploit modern processors without compromising support for older hardware

very odd choice of words. "better utilize/leverage" is perhaps the right thing to say here.

JohnKemeny 10/31/2025|

"exploit": make full use of and derive benefit from

More comments...