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
OpenPGP_signature
Description: OpenPGP digital signature
