8 ms·
Introducing architecture variants
- theandrewbailey 11mo agoA reference for x86-64 microarchitecture levels: https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels https://en.wikipedia.org/wiki/X86-64#Microarchitecture_level... x86-64-v3 is AVX2-capable CPUs.
- mananaysiempre 11mo agoRight, though compared to what one generally thinks of as an “AVX2-compatible” CPU, it curiously omits AES-NI and CLMUL (both relevant to e.g. AES-GCM). Yes, they are not technically part of AVX2, but they are present in all(?) the qualifying Intel and AMD CPUs (like many other technically-not-AVX2 stuff that did get included, like BMI or FMA3).
- justahuman74 11mo agoIf this goes well - will they do v4 as well?
- jnsgruk 11mo agoMaybe - likely we’ll trade-off the added build/test/storage cost of maintaining each variant - so you might not see amd64v4, but possibly amd64v5 depending on how impactful they turn out to be. The same will apply to different arm64 or riscv64 variants.
- mwhudson 11mo agoProbably not v4 unless AVX512 becomes more ubiquitous than it looks like it will. But yeah, I don't expect this to be the only variant ever.
- smlacy 11mo agoI presume the motivation is performance optimization? It would be more compelling to include some of the benefits in the announcement?
- embedding-shape 11mo agoThey 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 11mo agoARM/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/Ratified+Extensions https://riscv.atlassian.net/wiki/spaces/HOME/pages/16154732/... 2. https://developer.arm.com/documentation/dui0801/h/A64-Floating-point-Instructions/FJCVTZS https://developer.arm.com/documentation/dui0801/h/A64-Floati...
- mobilio 11mo agoAnnounce was here: https://discourse.ubuntu.com/t/introducing-architecture-variants-amd64v3-now-available-in-ubuntu-25-10/71312 https://discourse.ubuntu.com/t/introducing-architecture-vari... and key point: "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."
- juujian 11mo agoAre there any use cases where that 1% is worth any hassle whatsoever?
- adgjlsfhk1 11mo agoit's very no uniform. 99% see no change, but 1% see 1.5-2x better performance
- Insanity 11mo agoI read it as, across the board a 1% performance improvement. Not that only 1% of packages get a significant improvement.
- IAmBroom 11mo agoIn a complicated system, a 1% overall benefit might well be because of a 10% improvement in just 10% of the system (or more in a smaller contributor).
- darkwater 11mo agoThe announcement is pretty clear on this: > Previous benchmarks (...) 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.
- 2b3a51 11mo ago
- theandrewbailey 11mo agoA reference for x86-64 microarchitecture levels: https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels https://en.wikipedia.org/wiki/X86-64#Microarchitecture_level... x86-64-v3 is AVX2-capable CPUs.
- jsheard 11mo ago> x86-64-v3 is AVX2-capable CPUs. Which unfortunately extends all the way to Intels newest client CPUs since they're still struggling to ship their own AVX512 instructions, which are required for v4. Meanwhile AMD has been on v4 for two generations already.
- theandrewbailey 11mo agoAt least Intel and AMD have settled on a mutually supported subset of AVX-512 instructions.
- wtallis 11mo agoThe hard part was getting Intel and Intel to agree on which subset to keep supporting.
- cogman10 11mo agoEven on the same chip. Having a non-uniform instruction set for one package was a baffling decision.
- jsheard 11mo agoI think that stemmed from their P-core design being shared between server and client. They needed AVX512 for server so they implemented it in the P-cores, and it worked fine there since their server chips are entirely P-cores or entirely E-cores, but client uses a mixture of both so they had to disable AVX512 to bring the instruction set into sync across both sides.
- physicsguy 11mo agoThis is quite good news but it’s worth remembering that it’s a rare piece of software in the modern scientific/numerical world that can be compiled against the versions in distro package managers, as versions can significantly lag upstream months after release. If you’re doing that sort of work, you also shouldn’t use pre-compiled PyPi packages for the same reason - you leave a ton of performance on the table by not targeting the micro-architecture you’re running on.
- colechristensen 11mo agoMost of the scientific numerical code I ever used had been in use for decades and would compile on a unix variant released in 1992, much less the distribution version of dependencies that were a year or two behind upstream.
- owlbite 11mo agoVery true, but a lot of stuff builds on a few core optimized libraries like BLAS/LAPACK, and picking up a build of those targeted at a modern microarchitecture can give you 10x or more compared to a non-targeted build. That said, most of those packages will just read the hardware capability from the OS and dispatch an appropriate codepath anyway. You maybe save some code footprint by restricting the number of codepaths it needs to compile.
- physicsguy 11mo agoI mean that’s just lucky and totally depends on your field and what is normal - just as an example, we used the LLNL SUNDIALS package for implicit time integration. On Ubuntu 24.04 the latest version is 6.4.1 where the latest published is v7.5.0. We found their major version releases tended to require changes. There’s also the difference between being able to run and being able to run optimised. At least 5 years ago, the Ubuntu/Debian builds of FFTW didn’t include the parallelised OpenMP library. In a past life I did HPC support and I recommend the Spack package manager a lot to people working in this area because you can get optimised builds with whatever compiler tool chain and options you need quite easily that way.
- 11mo ago
- zozbot234 11mo agoWhat are the changes to dpkg and apt? Are they being shared with Debian? Could this be used to address the pesky armel vs. armel+hardfloat vs. armhf issue, or for that matter, the issue of i486 vs. i586 vs. i686 vs. the many varieties of MMX and SSE extensions for 32-bit? (There is some older text in the Debian Wiki https://wiki.debian.org/ArchitectureVariants https://wiki.debian.org/ArchitectureVariants but it's not clear if it's directly related to this effort)
- Denvercoder9 11mo agoEven if technically possible, it's unlikely this will be used to support any of the variants you mentioned in Debian. Both i386 and armel are effectively dead: i386 is reduced to a partial architecture only for backwards compatibility reasons, and armel has been removed entirely from development of the next release.
- zozbot234 11mo agoWhat you said is correct wrt. official support, but Debian also has an unofficial ports infrastructure that could be repurposed towards enabling Debian for older architecture variants.
- bobmcnamara 11mo agoThis would allow mixing armel and softvfp ABIs, but not hard float ABIs, at least across compilation unit boundaries (that said, GCC never seems to optimize ABI bottlenecks within a compilation unit anyway)
- mwhudson 11mo ago> Could this be used to address the pesky armel vs. armel+hardfloat vs. armhf issue No, because those are different ABIs (and a debian architecture is really an ABI) > the issue of i486 vs. i586 vs. i686 vs. the many varieties of MMX and SSE extensions for 32-bit? It could be used for this but it's about 15 years too late to care surely? > (There is some older text in the Debian Wiki https://wiki.debian.org/ArchitectureVariants https://wiki.debian.org/ArchitectureVariants but it's not clear if it's directly related to this effort) Yeah that is a previous version of the same design. I need to get back to talking to Debian folks about this.
- dfc 11mo ago> you will not be able to transfer your hard-drive/SSD to an older machine that does not support x86-64-v3. Usually, we try to ensure that moving drives between systems like this would work. For 26.04 LTS, we’ll be working on making this experience cleaner, and hopefully provide a method of recovering a system that is in this state. Does anyone know what the plans are to accomplish this?
- deleted 11mo ago[deleted]
- dmoreno 11mo agoIf I were them I would make sure the V3 instructions are not used until late in the boot process, and some apt command that makes sure all installed programs are in the right subarchitecture for the running system, reinstalling as necessary. But that does not sound like a simple for non technical users solution. Anyway, non technical users using an installation on another lower computer? That sounds weird.
- mwhudson 11mo agoI am probably going to be the one implementing this and I don't know what I am going to do yet! At the very least we need the failure mode to be better (currently you get an OOPS when the init from the initrd dies due to an illegal instruction exception)
- zer0zzz 11mo agoThere was a fat elf project to solve this problem at one point I thought.
- DrNosferatu 11mo agoLink?
- mariusor 11mo agoMaybe parent is referring to icculus' FatELF proposal from fifteen years ago? https://icculus.org/fatelf/ https://icculus.org/fatelf/
- zer0zzz 11mo agoYes I think that’s it
- DrNosferatu 11mo agoMaybe Jart's APE could "host" the multiple flavors of the executable: https://github.com/jart/cosmopolitan/blob/master/ape/specification.md https://github.com/jart/cosmopolitan/blob/master/ape/specifi...
- stabbles 11mo agoSeems 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 11mo agoNo 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.
- sluongng 11mo agoNice. 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 11mo agoCachyOS 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 11mo agocorrect, it just sets the repository in the pacman.conf to either cachyos, -v3, or -v4 during install time based on hardware probe
- shmerl 11mo agoWill Debian do it?
- bmitch3020 11mo agohttps://wiki.debian.org/ArchitectureVariants https://wiki.debian.org/ArchitectureVariants
- shmerl 11mo agoHm, discussion is from 2023. Did anything come out of it?
- bmitch3020 11mo agoI believe it's just discussions right now. If/when something happens, I'm hoping they'll update the wiki.
- amelius 11mo agoCan we please have an "apt rollback" function?
- riskable 11mo agoIf you're using btrfs, you do get that feature: https://moritzmolch.com/blog/2506.html https://moritzmolch.com/blog/2506.html
- o11c 11mo agoThat fundamentally requires a snapshot-capable filesystem, so you need to use a distro designed around such.
- amelius 11mo agoNot necessarily. You can use the ptrace() system call to trace a process and store what it reads/writes into a journal, etc. https://man7.org/linux/man-pages/man2/ptrace.2.html https://man7.org/linux/man-pages/man2/ptrace.2.html
- julian-klode 11mo agoYes sure apt (3.1.7) unstable; urgency=medium . [ Julian Andres Klode ] * test-history: Adjust for as-installed testing . [ Simon Johnsson ] * Add history undo, redo, and rollback features
- dima55 11mo agoExciting. I just looked for docs about these new features, and can't find anything. Can you point us to these? Thanks!
- benatkin 11mo agoThere's an unofficial repo for ArchLinux: https://wiki.archlinux.org/title/Unofficial_user_repositories#ALHP https://wiki.archlinux.org/title/Unofficial_user_repositorie... > Description: official repositories compiled with LTO, -march=x86-64-vN and -O3. Packages: https://status.alhp.dev/ https://status.alhp.dev/
- zdw 11mo agoMany 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.
- deleted 11mo ago[deleted]
- skywhopper 11mo agoThis 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.
- ElijahLynn 11mo agoI clicked on this article expecting an M series variant for Apple hardware...
- westurner 11mo ago"Gentoo x86-64-v3 binary packages available" (2024) https://news.ycombinator.com/item?id=39255458 https://news.ycombinator.com/item?id=39255458 "Changes/Optimized Binaries for the AMD64 Architecture v2" (2025) https://fedoraproject.org/wiki/Changes/Optimized_Binaries_for_the_AMD64_Architecture_v2 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).
- whalesalad 11mo ago> 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 11mo ago"exploit": make full use of and derive benefit from
- Hasz 11mo agoGetting a 1% across the board general purpose improvement might sound small, but is quite significant. Happy to see Canonical invest more heavily in performance and correctness. Would love to see which packages benefited the most in terms of percentile gain and install base. You could probably back out a kWh/tons of CO2 saved metric from it.
- malkia 11mo agoThis is awesome, but ... If you process requires deterministic results (speaking about floats/doubles mostly here), then you need to get this straight.
- tommica 11mo agoOnce they have rebuilt with rust, they get to move away from GPL licenses and get to monetize things.
- lotfi-mahiddine 11mo ago[dead]
- rock_artist 11mo agoSo 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 11mo agoI 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 11mo agoOTOH, 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 11mo agoThat'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.
- brucehoult 11mo agoSo now they can support RISC-V RVA20 and RVA23 in the same distro? All the fuss about Ubuntu 25.10 and later being RVA23 only was about nothing?
- snvzz 11mo agoThey sure can, but it seems they simply did not want to.
- watersb 11mo agoOver the past year, Intel has pulled back from Linux development. Intel has reduced its number of employees, and has lost lots of software developers. So we lost Clear Linux, their Linux distribution that often showcased performance improvements due to careful optimization and utilization of microarchitectural enhancements. I believe you can still use the Intel compiler, icc, and maybe see some improvements in performance-sensitive code. https://clearlinux.org/ https://clearlinux.org/ "It was actively developed from 2/6/2015-7/18/2025."
- dooglius 11mo agoicc was discontinued FWIW. The replacement, icx, is AIUI just clang plus some proprietary plugins
- watersb 11mo agoI wonder how this relates to Intel's "One API", which extends a single C code base across the various CPU targets (such as the core ALU, base vector units, AVX-512, NPU) and Intel GPU accelerators. Not the same thing, or perhaps an augmentation of Intel performance libraries (which required C++, I believe). Sure, harmonizing all of this may have suggested that there were too many software teams. But device drivers don't write themselves, and without feedback from internal software developers, you can't validate your CPU designs.
- wyldfire 11mo agoWould we have something like aarch64 neon/SVE too?
- random29ah 11mo agoI'm really "new" to x64 (I only migrated from 32-bit in 2020...) and the difference I noticed between x86-64-v1 and x86-64-v3 was only with video (with ffmpeg), audio (mp3/ogg/mp4...) and encryption; the rest remains practically the same. Naively, I believe it might be more appropriate to have x86-64-v1 and x86-64-vN options only for specific software and leave the rest as x86-64-v1. AVX seemed to give the biggest boost to things. Regarding those who are making fun of Gentoo users, it really did make a bigger difference in the past, but with the refinement of compilers, the difference has diminished. Today, for me, who still uses Gentoo/CRUX for some specific tasks, what matters is the flexibility to enable or disable what I want in the software, and not so much the extra speed anymore. As an example, currently I use -Os (x86-64-v1) for everything, and only for things related to video/sound/cryptography (I believe for things related to mathematics in general?) I use -O2 (x86-64-v3) with other flags to get a little more out of it. Interestingly, in many cases -Os with -mtune=nocona generates faster binaries even though I'm only using hardware from Haswell to today's hardware (who can understand the reason for this?).