Arch Linux Developers Discuss Idea Of Providing An x86-64-v3 Port

[bug77]

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).

Yes. I understand the rationale behind not going cutting-edge, but having everyone on pre-Nehalem code base because .1% of the population still runs old systems just doesn't seem right.

[Grinch]

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 ?

That would only make sense if you intended to recompile all the packages. Arch is a binary distro, meaning it distributes binaries, no matter what you change your makepkg.conf to, the binaries you download won't change.

If/when v3 is introduced, you will need to edit your /etc/pacman.conf and enable the v3 repository.

[Mat2]

Yes. I understand the rationale behind not going cutting-edge, but having everyone on pre-Nehalem code base because .1% of the population still runs old systems just doesn't seem right.

As my benchmarks have shown, there is no or virtually no performance benefit of compiling for x86_64-v2. GCC 9 simply is not able to make good use of SSE3/SSSE3/SSE4.

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='.

This.

Most of the programs that get a big performance boost from using AVX/AVX2 already use these extensions. They use hand-crafted assembly or C language asm intrinsics. This includes the most important audio-video codecs, programs for scientific computation and number crunching, etc. Most software does not process big number arrays and so does not benefit that much from SIMD.

The workload that got the most boost in the benchmark was John the Ripper with MD5, perhaps because noone really cared to optimize it for AVX/AVX2. Other then this, the performance gains were modest - around 10% - 20%. I have tried to exclude binaries that use much asm, because there was really no point in benchmarking them.

[Alaska23]

Most UEFI installs still use GRUB though?

Well after upgrading my hardware to a modern ryzen x570 system, I eventually decited to change the legacy boot in grub to UEFI for my archlinux system.
What a mess! Really - didn't get this setup booting via UEFI. While eg. in Ubuntu, the installer does this for you, changing it on an existing system is a nightmare.
So I checked the Arch Wiki and decited to use systemd boot ... How easy, how nice!! So in case you want to switch to UEFI boot and do not need old bios boot, dump grub2 and switch to systemd boot,

[Mat2]

While Alan didn't go into it, v3, from what I can tell, is also UEFI-only.

A lot of modern servers still use BIOS. This applies also to most virtual machines.

Correctly setting up UEFI with RAID is tricky and not handled well in current distributions. This usually involves using old mdadm formats or multiple EFI System Partitions, one for every device. BIOS is much simpler.

Also, there is really no point in using LUKS2 in GRUB. Just use a separate /boot partition.

[Vistaus]

a lot of modern servers still use bios. This applies also to most virtual machines.

Correctly setting up uefi with raid is tricky and not handled well in current distributions. This usually involves using old mdadm formats or multiple efi system partitions, one for every device. Bios is much simpler.

Also, there is really no point in using luks2 in grub. Just use a separate /boot partition.

bios =! Uefi

Edit: why can't I post words in caps when the words *are* supposed to be written in caps? Annoying forum software.

[Mat2]

When I was writing BIOS, I really meant the legacy BIOS.

[StarterX4]

Hell yeah, this is what my Skylake was waiting for.

[oleid]

As my benchmarks have shown, there is no or virtually no performance benefit of compiling for x86_64-v2. GCC 9 simply is not able to make good use of SSE3/SSSE3/SSE4.


This.

Most of the programs that get a big performance boost from using AVX/AVX2 already use these extensions.

It depends. Anything which uses Eigen3 and longer vectors will be faster when optimizing for the target architecture.

[jeisom]

I am wondering how much the of just tuning for a more modern baseline, but keeping the arch the same. Couldn’t scheduling in the compiler for newer chips make a difference?