Serpent OS To Require x86_64-v2 CPUs While Offering x86_64-v3 Packages Too

[phoronix]

Phoronix: Serpent OS To Require x86_64-v2 CPUs While Offering x86_64-v3 Packages Too

Serpent OS as the latest Linux distribution project of well known developer Ikey Doherty is off to a great start for 2024. Following all their Rust infrastructure work last year, that infrastructure work has continued while also taking on new challenges for the new year...

https://www.phoronix.com/news/Serpent-OS-January-2024

[ms178]

Great that they will offer x86-64-v3 packages on compatible devices. Maybe they'll looka at a superset of that again which was thought about years ago and contains several other instructions compatible with CPUs of that era. After all it is 2024, and I can't wait to get my hands on a usable ISO (hopefully with a KDE variant) eventually.

[spiral_23]

whether with kde or gnome - to give the when ready the release a try is a must!

[ermo]

Great that they will offer x86-64-v3 packages on compatible devices. Maybe they'll looka at a superset of that again which was thought about years ago and contains several other instructions compatible with CPUs of that era. After all it is 2024, and I can't wait to get my hands on a usable ISO (hopefully with a KDE variant) eventually.

It will be a custom superset (-v3x, not plain -v3) that supports haswell/zen1 and up, while offering performance improvements in encryption and compression workloads in particular, due to the specific extra instructions enabled, yes.

I'm still researching whether the instructions added will be supported by AMD Excavator CPUs. If someone with one of those could paste or attach the contents of their /proc/cpuinfo file, that'd be very helpful.

If even phoronix readers don't have Excavator CPUs, then I'm pretty sure it'll be no big loss that they won't be supported in the -v3x target after all...

Initially, the plan is to bring up a GNOME only environment for dog-fooding purposes, which relies heavily on flatpaks (which we may or may not decide to rebuild and host for our targets) so as to enable quicker iteration on the base system, tooling and necessary full-repo (test-)rebuilds.

[NotMine999]

The intentions of this developer are noble.

Can't want for all the sloppy GUI coders out there to bog it down ala Windoze with loads and loads of useless CPU-grinding "features" THAT YOU GOTTA HAVE !

[coder]

It will be a custom superset (-v3x, not plain -v3) that supports haswell/zen1 and up, while offering performance improvements in encryption and compression workloads in particular, due to the specific extra instructions enabled, yes.

v3x is not a "thing". What Haswell instructions are missing from v3, relative to these workloads?

I'm still researching whether the instructions added will be supported by AMD Excavator CPUs. If someone with one of those could paste or attach the contents of their /proc/cpuinfo file, that'd be very helpful.

This is well-known information, though I can't find an easy or official reference. Apparently, it does support Excavator, but that also explains why it lacks some of the instructions you're probably referring to, above.

https://discuss.getsol.us/d/10152-solus-5-and-x86-64-v3-target

[ms178]

v3x is not a "thing".

While not an "official" thing, I welcome any performance benefits that come from using these extra instructions found on Haswell and Zen 1 over the normal v3-definition, especially when v2 is still available for these other targets as a fallback. While this excludes some unpopular AMD architectures of that era from getting the v3-packages, this might not be a big loss overall due to limited market share of these and their AVX2 implementation wasn't that great either.

[ermo]

v3x is not a "thing". What Haswell instructions are missing from v3, relative to these workloads?

I am well aware. We had to call it something though, so -v3 with extensions / extended -v3 became -v3x for convenience.

The extensions in question we (currently) plan to use for -v3x are listed in Joey's post that you linked to (he and I discussed how to frame a subset of that post before he put it up, and I just edited said post because it had a small error in one of the compiler feature names).

Credit where credit is due, it was sunnyflunk who originally came up with the -v3x superset after doing extensive research and benchmarks.

The reason I ask for excavator /proc/cpuinfo files is that we do feature tests based on them, meaning that the basic skeleton is portable to architectures where linux runs ootb. And I don't have access to one myself.

[coder]

While not an "official" thing, I welcome any performance benefits that come from using these extra instructions found on Haswell and Zen 1 over the normal v3-definition,

Fine. Screw standards, then. Let every distro do its own thing and enjoy the chaos that follows.

Or, why not embrace the glibc runtime loading mechanism, so people can at least get the benefit of this functionality on v4 CPUs?

[ms178]

Fine. Screw standards, then. Let every distro do its own thing and enjoy the chaos that follows.

Isn't Linux a mess when it comes to distro standards anyway? I see no real damage by having a relatively minor distro using such superset that exclude only some older AMD architectures that have no market relevance these days any longer.

Or, why not embrace the glibc runtime loading mechanism, so people can at least get the benefit of this functionality on v4 CPUs?

We've had that discussion before and it seems the Serpent/Solus devs made an elaborate decision for the other way.