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

[Eli Schwartz]

On 3/2/21 7:54 PM, Allan McRae via arch-dev-public wrote:
> 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?

I wonder, might this be an interesting time to reintroduce multiple
architectures?

We used to offer i686 and x86_64.

Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go right
to -v4.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20210302/e2f2f1b3/attachment.sig>