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" <msuchanek@suse.de>:
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.

Thanks

Michal
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.