SUSE's Adaptable Linux Platform Considers Requiring AVX-Capable x86_64 CPUs

[phoronix]

Phoronix: SUSE's Adaptable Linux Platform Considers Requiring AVX-Capable x86_64 CPUs

The SUSE/openSUSE Adaptable Linux Platform (ALP) that is being viewed as the eventual successor to SUSE Linux Enterprise 15 is likely to require higher system requirements for x86_64 CPUs. Just how much newer the Intel/AMD support requirement will be has yet to be firmly decided but they are looking at a baseline of "x86-64-v3" that would effectively mean requiring Advanced Vector Extensions (AVX)...

https://www.phoronix.com/scan.php?page=news_item&px=SUSE-ALP-x86-64-Raising-Base

[coder]

AVX/AVX2 requirements are going to fail for SUSE for the same reasons Fedora abandoned the plan. Too many low-end Intel CPUs, some still current, don't support AVX.

Jasper Lake is used in the overwhelming number of new Intel chromebooks, entry-level laptops, and even their entry-level NUCs. Elkhart Lake is used in lots of industrial applications. And then there's the Atom C-series and P-series, (Parker Ridge & Snow Ridge) which are used in other embedded applications.

hwcaps is their best option, and should make this dilemma much less pressing.

[mangeek]

I would very much like if Ubuntu had two builds: One that was like today's lowest common denominator, and a 'x86_64_perf' that targeted mainstream CPUs that could reasonably be expected to be currently deployed and under warranty at companies (which I believe would be x86-64-v3 these days).

[coder]

I would very much like if Ubuntu had two builds: One that was like today's lowest common denominator, and a 'x86_64_perf' that targeted mainstream CPUs

Wouldn't it be easier just to package key libraries with 2-3 versions for different hwcaps levels? You could do that today, if your glibc version is >= 2.33.

[MorrisS.]

Would be a big progress.

[guspitts]

Speaking of x86_64-v3, Michael, have you ever considered doing a suite of benchmark with Arch Linux using the ALHP repositories? https://git.harting.dev/ALHP/ALHP.GO . This repo recompiles all of the Arch packages for x86_64-v3.

I use it on my machine and it is running fine. Hard to tell on a desktop if it makes an objective difference. I would be curious what benchmarks have say. And it is a relatively easy way to do an apple-to-apple comparison of the benefits of the x86_64-v3 target versus plain old x86_64.

[jabl]

Wouldn't it be easier just to package key libraries with 2-3 versions for different hwcaps levels? You could do that today, if your glibc version is >= 2.33.

You can even make do without hwcaps if you want. Back in the day Debian used to provide a separate libc6-i686 package which replaced the normal libc6 package (built for i486).

But sure hwcaps, function multiversioning and such make it easier and more convenient.

[skeevy420]

AVX/AVX2 requirements are going to fail for SUSE for the same reasons Fedora abandoned the plan. Too many low-end Intel CPUs, some still current, don't support AVX.

Jasper Lake is used in the overwhelming number of new Intel chromebooks, entry-level laptops, and even their entry-level NUCs. Elkhart Lake is used in lots of industrial applications. And then there's the Atom C-series and P-series, (Parker Ridge & Snow Ridge) which are used in other embedded applications.

hwcaps is their best option, and should make this dilemma much less pressing.

I was reading about it earlier today and those Intels are basically why RHEL9 is using v2.

I find it very ironic that the company making the arguably fastest and most optimized Linux distribution is the same company that makes the low-end CPUs that just happen to be the limiting factor holding everyone else up in regards to compiler and OS optimizations. Just a coincidence

[JacekJagosz]

hwcaps is their best option, and should make this dilemma much less pressing.

Wouldn't it be easier just to package key libraries with 2-3 versions for different hwcaps levels? You could do that today, if your glibc version is >= 2.33.

You are certainly correct, and I know Solus has been doing that for years, providing x86-v2 for everything and Haswell (v3 with a few more instructions) for some most crucial components. And I can tell it is not ideal. First, you are only doing it for certain, most critical packages, ones that you are sure will bring benefit. So you are missing on optimizing all apps. Also, on Solus it doubles building time for those packages, which is annoying. Also, you are shipping twice the amount of files to support that.
It certainly is possible and works, but it would be considerably easier to just support v3. It would also mean less split in testing time, with half the versions to test, and there has been some issues with haswell version of glibc for example on Solus. Much easier to catch those if you only have one.

[ms178]

Speaking of x86_64-v3, Michael, have you ever considered doing a suite of benchmark with Arch Linux using the ALHP repositories? https://git.harting.dev/ALHP/ALHP.GO . This repo recompiles all of the Arch packages for x86_64-v3.

I use it on my machine and it is running fine. Hard to tell on a desktop if it makes an objective difference. I would be curious what benchmarks have say. And it is a relatively easy way to do an apple-to-apple comparison of the benefits of the x86_64-v3 target versus plain old x86_64.

That is indeed a great benchmarking idea. I've also used it for some time now, there is also CachyOS (performance-oriented Arch-derivative) which provides v3-packages, the repo is also usable on other close-to-upstream Arch-derivatives, e.g. EndeavourOS. In my own game testing, the v3-repo itself didn't yield too much improvements in terms of FPS though while a customized Xanmod-Kernel yielded far more performance benefits (from around 42 fps > 94 fps in Company of Heroes 2; with further customizations I get around 101 fps avg).