[arch-dev-public] RFC: Use x86_64-v2 architecture

[Allan McRae]

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-linux-9-for-the-x86-64-v2-microarchitecture-level/