How about this, let the "vanilla" Alp still run on all x86-64 levels, and if someone actually has a workload that would really benefit from the more optimized binaries, have them add another repository and run zypper dup. Could even be done during install.
Am 27. September 2022 18:14:07 GMT-04:00 schrieb "Michal Suchánek" firstname.lastname@example.org:
On Tue, Sep 27, 2022 at 07:34:59PM +0200, Stephan Kulow wrote:
Am 27.09.22 um 18:39 schrieb Michal Suchánek:
If ALP is about adaptability wouldn't it make more sense to figure out how to deliver packages built to take advantage of the most modern CPU extensions where it matters without raising the bar in general?
That's already the plan to support V3 hardware. We really have to measure this. If it's e.g. only crypto algorithms benefiting, it's a different discussion to have than if it's multimedia codecs or if it's general workloads (like spellcheking emails).
Yes, crypto algorithms and multimedia codecs can typically benefit a lot from new CPU features (in absence of hardware accelerators).
Some libraries that benefit a lot from new CPU features support dynamic dispatch upstream, and are built to make use of it. For these benefit of compiling for newer architecture will be minimal if any.
And sure, compiling your e-mail client for x86_64-v4 can make spellchecking your mail a few % faster. The thing is, how much time do you spend waiting for your e-mails to be spellchecked? Typically none as opposed to typing them, fetching them from the server, and sending them.
And that's the thing: for vast majority of code being able to run it a few % faster makes absolutely no difference for vast majority of use cases.
And for a lot of code it would be great to run it faster but the bottleneck is not the CPU so the new instructions don't really help.