OpenSUSE Developers Continue Discussing x86_64 Microarchitecture Feature Levels

[coder]

"Than average", sure, but there are a LOT of gamers who don't fit the "teenage boy with a PC (and mouse and keyboard) that looks like the Las Vegas strip" stereotype, and a lot of them run HW that *by* gaming standards is pretty much potato.

But that "hardcore" set is going to skew the population towards newer & higher end hardware than your typical Linux install will use.

There's another factor affecting Steam usage, which is that even non-hardcore games will not tend to game much, if the experience is bad. Hence, those with older & lower-end machines will tend to drop out of the survey.

Again, this is about population statistics, and you can't deny that gaming involves factors which will skew the statistics towards newer & higher-end machines than what the general computing public is using. Furthermore, Linux has some factors probably skewing its users towards older machines, because Linux users tend to be more technical and therefore more willing & able to keep old machines running.

[arQon]

And gamers (i.e. the people using Steam) are more likely than average to be running newer & higher-end hardware.

"Than average", sure, but there are a LOT of gamers who don't fit the "teenage boy with a PC (and mouse and keyboard) that looks like the Las Vegas strip" stereotype, and a lot of them run HW that *by* gaming standards is pretty much potato.

The largest group for Intel CPUs, for example, is 2.3 Ghz to 2.69 Ghz. That smells like laptop, which means it may well be running on integrated graphics and will have serious noise and thermals issues either way. (And the third largest only improves that to 2.7 Ghz to 2.99 Ghz, with the two of them combined adding up to over 30%).

https://store.steampowered.com/hwsurvey used to break it down by CPU, which was a lot more interesting (and had the i3 dominant) it's more opaque now. It also doesn't show C/T, which is pretty annoying.

[xorbe]

Instead of x32 and x64, how about recent x64 and older x64.

[arQon]

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.

Intel is still releasing new CPUs as of *last year* that don't support v3, and not just "some" but *"most"* of those systems will still be in use at least 5 years from now, and possibly as many as 10. The argument that "v3 is Haswell and therefore all CPUs still in service have it" isn't just hopelessly wrong in its own right, it's so wrong that it isn't even framing the issue correctly.

There just isn't a sane way to handle this other than making a *runtime* decision.

The next best option would probably be something along the lines of Ubuntu's HWE approach, with machines opting in to higher feature levels, but nobody's going to burn the resources on producing something like that when only a fraction of their users care about it in the first place.

[coder]

No idea about SUSE, but 13% of Steams users do not have v3. 1.1% do not have v2.

And gamers (i.e. the people using Steam) are more likely than average to be running newer & higher-end hardware.

[carewolf]

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?

No idea about SUSE, but 13% of Steams users do not have v3. 1.1% do not have v2.

[coder]

Can't they maintain two branches, one for AVX2 and one for non-AVX2? That way, people with AVX2 could benefit while others won't be left unsupported. Then, at a future date, they could simply drop the latter.

HWCAPS has this ability, but you can choose which among the 4 architecture versions to support, on a package-by-package basis. That way, you don't need to bother with special builds for packages and architecture versions which don't benefit (hint: Phoronix Test Suite can help you determine which ones these are!).

[Vorpal]

What people seem to be missing is that with hwcaps you can have your cake and eat it too. Sure, not everything will be easy to build that way. But not everything needs it. Most software I use is not performance critical. I don't care if my text editor, email client or terminal emulator is built with a more modern target. Not do I care about the settings application of my DE of choice.

The way I see it, they should target getting hwcaps up and running for glibc, language runtimes (libstdc++, python, perl etc), and any libraries that are deemed to be performance critical for tasks where performance actually matters.

That way the overall build times will only increase moderately while still getting a lot of "bang for the buck" as Americans say.

Media libraries came to mind as a possible category for optimisation, but given that most of those probably already use optimised code paths with inline asm or intrinsics, it probably won't make a difference.

Compilers (gcc, clang, rustc) might be a good target too, as something that takes a lot of runtime. Though I don't know how much x86-v3 would help there. Benchmarking is needed.

[Vistaus]

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.

Can't they maintain two branches, one for AVX2 and one for non-AVX2? That way, people with AVX2 could benefit while others won't be left unsupported. Then, at a future date, they could simply drop the latter.

[pWe00Iri3e7Z9lHOX2Qx]

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.

Again, this might not matter. How many Leap users are on these systems? Maybe > 90% of Leap users are on AVX capable systems. Basing hardware decisions for your specific distro on what could possibly be out there resulting in systems that are slower for everyone else isn't good product planning. There will always be Antix and other distros targeting low end hardware.

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.

I'm all for whatever solution moves the ball forward on performance and actually gets implemented by the distros.