On 2/3/21 9:51 pm, Allan McRae wrote:
Hi all,
A new RFC has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2
Summary: Make -march=x86_64-v2 the default for our packages. This assumes the following instruction sets which are essentially available on all but the oldest AMD CPUs:
CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
Please visit the above link for discussion.
I'm following this up with a more detailed explanation than in the RFC, because this is really a discussion about the core of Arch Linux. The clear disadvantage of this proposal is that processors older than ~2008 will no longer be supported. We have heard from people who run Arch on these processors, because they will be affected. But that does not mean theses are a high proportion. I suspect we caused more people to not be able to run Arch when we dropped i686 (based purely on the size of the immediate outrage...). What are the advantages? Optimization of binaries. It has been pointed out that glibc and some other packages do hardware detection that allows the use of optimized routines for some functions, so this limits benefits. Great for that software, but not all software than can benefit does this. Also some packages already have variants provided with a -sse4 or -avx2 suffix where there is a major benefit. But this is done on an as-wanted basis, and is a maintenance burden. While the performance gains we will get are debatable in size, another major benefit is power usage. I recompiled my entire system as a test last year to something equivalent to x86_64-v3 (so more optimised than the proposal) and saw a *substantial* increase in battery life on my laptop under usual usage. So there are advantages beyond pure speed improvements. I think this discussion comes down to how Arch Linux wants to position itself and its guiding philosophies. In the early days, the selling points of Arch were rolling release, optimised binaries, and simple packaging (including lack of splitting). We still do rolling release. But I'd venture that openSUSE Tumbleweed does it in a more robust way these days. Our lack of package splitting (e.g. including development headers in the package), does have significant advantages still. However, we have lost our lead on optimized binaries. When we provided i686, other distros were still doing i386 or maybe i486. At that stage, Arch was rejecting older processors. RHEL have announced they will use x86_64-v2 for EL9 [1]. I have not seen any discussion of this, but you would assume Fedora would do it first. Given SUSE was involved in the definition of the three new x86_64 microarchitectures, I'd expect them to move there too. That would make Tumbleweed very attractive over Arch (and I say that with a vested interest in the Arch package manager...). Is Arch a distribution that supports processors that are more than a decade old? There are dozens of other distros that do that too. Or do we drop support for a small fraction of hardware in current use (as we have done on previous occasions) and continue to push the boundaries of a binary based Linux distribution? Are we a distribution that takes a leap before other distros, or just another rolling release distro? Allan [1] https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-li...