If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Announcement
Collapse
No announcement yet.
Arch Linux Developers Discuss Idea Of Providing An x86-64-v3 Port
I get that we should raise the minimum requirements, as it doesn't make any sense to run 2021 OS and software on late 90s and early 2000s hardware but why are they pushing AVX as minimum?
Does it really matter on OS-level? What are the benefits?
Also, there are new CPUs from both Intel and AMD that do not have AVX. For example Intel Pentium Gold G6600 was released in 2020 and AMD A8 7680 was released in 2019.
Are the benefits so big that we are willing to abandon new CPUs?
I can understand that but the speed benefit from forcing AVX2 over AVX1 in general use does not seem that big. Oh well, maybe someone will come along and make a v2.5 and then i will be covered.
Compilers are notoriously poor at making very efficient use of specialized registers, which is why programs that can benefit greatly from them very often use hand-written assembly when utilizing them.
Said programs typically check at runtime what your CPU supports, and use the appropriate assembly code, so their performance doesn't really depend much on being compiled for a specific '-march='.
So, to set switch to v3 for my existing Arch install, all I have to do is add -march=x86-64-v3 and -flto flags to CFLAGS and CXXFLAGS parameters in my /etc/makepkg.conf or is there something else I'm missing ?
So, to set switch to v3 for my existing Arch install, all I have to do is add -march=x86-64-v3 and -flto flags to CFLAGS and CXXFLAGS parameters in my /etc/makepkg.conf or is there something else I'm missing ?
You could also just use CFLAGS/ CXXFLAGS with ="-march=native -O2 -pipe -fstack-protector-strong" and it will be even better than just x86-64-v3.
So, to set switch to v3 for my existing Arch install, all I have to do is add -march=x86-64-v3 and -flto flags to CFLAGS and CXXFLAGS parameters in my /etc/makepkg.conf or is there something else I'm missing ?
You'd need the newest glibc 2.33 and GCC 11.0.1 at the minimum for feature levels to be supported, chances are that you are on an older toolchain. But you can try -march=native for your CPU. I'd add -flto=auto also for LDFLAGS to be on the safe side but I'd need to test if that is really neccessary for using all of your cores with LTO during the linking stage.
So, to set switch to v3 for my existing Arch install, all I have to do ...
... all you have to do is wait for this proposal to come through and get implemented. As of now, Arch does not offer any ports to newer x86_64 variants.
For self-built packages, though, yes, you can do that.
So, to set switch to v3 for my existing Arch install, all I have to do is add -march=x86-64-v3 and -flto flags to CFLAGS and CXXFLAGS parameters in my /etc/makepkg.conf or is there something else I'm missing ?
To make some tests
equivalent to x86-64-v3 using current GCC and LLVM, we can compile
packages using:
::
CFLAGS="$CFLAGS -mcx16 -msahf -mpopcnt -msse3 -msse4.1 -msse4.2 -mssse3 \
-mavx -mavx2 -mbmi -mbmi2 -mf16c -mfma -mlzcnt -mmovbe -mxsave"
CXXFLAGS="$CFLAGS"
Sarcasm aside I see why you misunderstood, I worded it badly. I'm asking why people/companies in general want AVX as minimum for the OS, not Arch Linux devs specifically. RedHat (and therefore RHEL, CentOS, Fedora), Intel, Canonical and a few others want to raise the minimum requirements and not provide separate "v2" and "v3" releases.
Also this is still a suggestion not a fact, so Arch devs could go directly to raising the minimum requirements and not do separate releases. Honestly, it would make sense for such a bleeding edge distro.
Last edited by StanGenchev; 16 March 2021, 11:54 AM.
Why not go the FatBinary approach. Compile different Versions and link them in one file. And let the CPU Dispacher choose the correct codepath for the system. Full Compatibility with best performance, just for the price of a bit more space required on mass storage.
If I remember correctly this approach increases binary sizes by a lot. This approach also limits your optimization opportunities (e.g. as others in this thread pointed out already there are improvements to be had by standardizing on a UEFI-only boot process which are a byproduct of the newer platform but don't have something to do with the ISA; I am sure that there are other new platform or CPU features which could further improve performance or usability if you would make such a hard cut in compatibility).
I concur. I think the new proposal is a good compromise between offering options for both progressives and legacy users, maintenance and infrastructure burden. And after some time they can move entirely to v3 (and start offering a v4 build when Alder Lake/Zen 4 and their successors spread AVX-512 into the mainstream market in volume).
Comment