OpenSUSE Developers Continue Discussing x86_64 Microarchitecture Feature Levels

[coder]

For enterprise targeted distros (where the real money is) one is mostly looking at the server class products where v3 is probably close to being on all the deployed equipment.

SuSE used to have a product called SLED (SuSE Linux Enterprise: Desktop). Does that still exist? Is that not a user segment that ALP is meant to address? Do we not think enterprises are running their distro of choice on mini-desktops and things like point-of-sale terminals?

While HWCAPS can be a solution for some, applications (and/or their build systems) need to be modified to do so, making it problematic for some.

I understand it's not a magic bullet, but the number of packages that would benefit significantly from v3 is also pretty small (probably < 1%?). So, there should be a relatively small amount of work to get most of the benefits.

Red Hat regularly moves the bar forward for their platforms, and EL9 for x86_64 requires v2 (which was apparently based on asking their enterprise customers what those customers had deployed as of a few years ago when the architecture target was decided).

All that argues is to move to v2.

I don't think anyone will be surprised when it gets raised to v3 in some future release.

Unless/until they announce definite plans for moving to v3, this point is moot.

other enterprise distros are going to move forward too, and those enterprise distros are only trying to decide on the when, not the if.

Nobody is arguing to stay on v1 or v2 forever. Just not to go to v3, when lots of new hardware is still being sold that's v2-only. Sheesh. Talk about lack of nuance.

[CommunityMember]

I think the main obstacle for distro maintainers to default to x86_64_v3 is that Pentium and Celeron CPUs don't support AVX2 until recently.

For enterprise targeted distros (where the real money is) one is mostly looking at the server class products where v3 is probably close to being on all the deployed equipment. However, as you point out, consumers (and especially people hanging on to their older systems) may not be running such systems. The performance advantages for v2 and v3 are somewhat compelling for some applications (and even more compelling when you are running large server farms). While HWCAPS can be a solution for some, applications (and/or their build systems) need to be modified to do so, making it problematic for some.

Red Hat regularly moves the bar forward for their platforms, and EL9 for x86_64 requires v2 (which was apparently based on asking their enterprise customers what those customers had deployed as of a few years ago when the architecture target was decided). I don't think anyone will be surprised when it gets raised to v3 in some future release. Since "out of the box" performance is a common testing criteria, other enterprise distros are going to move forward too, and those enterprise distros are only trying to decide on the when, not the if.

[coder]

whenever "instrumentation" (i.e. reporting home) is brought up you get into a mess of privacy issues, which no one has yet offered a way to both make things truly anonymous while not supporting ballot stuffing.

My employer makes appliances which typically don't have access to the public internet. So, you automatically miss a subset of the population, even before considering the "paranoid" folks.

Probably a lot of corporate environments would disable telemetry, as well.

[coder]

Will weird and wonderful landfill-chromebooks constitute a meaningful percentage of the opensuse ALP userbase in ~2024?

I'm not so concerned about "disposable" chromebooks, but it's a popular platform for mini-PCs, embededd, and industrial applications. And those sorts of devices can easily stick around for a decade.

[Jedibeeftrix]

You're looking at the wrong thing. Instead of looking at when the first CPU was released that supported v2 features, you need to look at when the last CPUs were released that don't support v3.

You're not wrong, but in so far as that statement is relevant to this point:

"Without hard data showing that a meaningful percentage of your user base will be impacted"

Will weird and wonderful landfill-chromebooks constitute a meaningful percentage of the opensuse ALP userbase in ~2024?

[CommunityMember]

The feature level debates are just one of a million reasons that distros need some instrumentation to make better product decisions.

While almost everyone agrees that guesses do not work well, whenever "instrumentation" (i.e. reporting home) is brought up you get into a mess of privacy issues, which no one has yet offered a way to both make things truly anonymous while not supporting ballot stuffing. If you have a good answer, please implement it (as many distros and applications will win with better data).

[coder]

According to ark.intel.com, both Jasper Lake and Elkhart lake actually launched in 2021:

• https://ark.intel.com/content/www/us...sper-lake.html
• https://ark.intel.com/content/www/us...hart-lake.html

[coder]

There are people in this thread recommending SSE3 as the baseline which will be at least TWENTY years old by the time ALP ships.

No, CPUs supporting the full v2 instruction set weren't released until 2010. v2 is equivalent to -march=westmere.

https://en.wikipedia.org/wiki/Westmere_(microarchitecture)

Without hard data showing that a meaningful percentage of your user base will be impacted because they run Pentium / Celeron / Atom, it seems insane to hold your shiny new platform back that far.

You're looking at the wrong thing. Instead of looking at when the first CPU was released that supported v2 features, you need to look at when the last CPUs were released that don't support v3. And those are still shipping in new systems, as of today. Chromebooks, entry-level laptops, low-end NUCs, mini-PCs, and embedded.

https://www.servethehome.com/new-int...ge-processors/

Again, why not simply use glibc's HWCAPS? Nobody seems to answer this. It lets you make progress at a faster rate -- even enabling you to utilize v4 -- without having to leave people behind.

[pWe00Iri3e7Z9lHOX2Qx]

personally i'd vote for v3, but that is because by the time ALP arrives my entire PC estate will be Zen3 or newer.

This is a valid point. ALP isn't coming out tomorrow, it won't be available until 2024 at the earliest. There are people in this thread recommending SSE3 as the baseline which will be at least TWENTY years old by the time ALP ships. Without hard data showing that a meaningful percentage of your user base will be impacted because they run Pentium / Celeron / Atom, it seems insane to hold your shiny new platform back that far.

[coder]

So much slicing and dicing, trying to find the least evil, when better tooling would be a simple and straightforward fix. We could sit here all day arguing over where to draw the line in the sand, or just patch the package manager to read the CPU info and check some package tags.

What about just using glibc's HWCAPS? They were kinda made to solve this very problem.

Then all the packages are compiled for v1 if you like, and anything performance sensitive ranging from the kernel to browsers to databases can be additionally compiled with v4 (or whatever combination) and selected where supported. Minimum compilation, no lost users, potential support for future package customizations.

HWCAPS can do this, too. What people tend to miss is that HWCAPS can enable more aggressive adoption/support for v3 and even v4, without having to drag everyone else along.