Hi Bruno, Am Mi., 21. Dez. 2022 um 17:01 Uhr schrieb Bruno Pitrus :

Hwcaps wastes disk space for a niche use case (moving an installation frequently between machines with different CPUs)

only for the case where you want the performance increase of going with a newer microarchitecture, for the libraries that you select to install, and where the recompiled library is actually worth it.

and IIRC is currently broken bc glibc and GCC have different ideas of what a given microarch corresponds to.

A fix for that has been submitted by Fabian as far as I know.

the right way to do this is what glibc does with i586/i686.

Are you referring to IFUNCs? e.g. per function differently compiled code that by runtime resolves to a different implementation? Otherwise, please elaborate? While custom IFUNCs are a nicer solution, it also requires either a compiler that can automatically produce it (afaik no open source implementation exists) or a lot of manual implementation to get upstream. It can still be mixed with this approach. Greetings, Dirk

I maintain the nodejs-electron package. I guess it could benefit from a v2/v3 build, which the hwcaps solution would not allow. This software's upstream claims that merely allowing SSE3 (which isn't even x86-64-v2) produces a significant speed boost and have dropped support for baseline x86-64 in their official builds.

Hi Fabian, Am Do., 22. Dez. 2022 um 15:12 Uhr schrieb Fabian Vogt :

The question is what's more niche, moving installations or hwcaps being worth it? I think we might end up needing both hwcaps libs + -vX specific packages.

Agreed, we can always choose to provide both, it's just not yet very well supported in the software stacks yet. something that hwcaps neatly avoids. The main issue is that the rpm architecture is slightly ambiguous now. In ALP, x86_64 is actually x86_64_v2, while in Tumbleweed it is baseline (and in the future there would be an x86_64_v3). fun.

There's the target_clones attribute which handles clones and dispatching automatically. It's supported by GCC as well as Clang:

__attribute__((target_clones("default", "avx", "avx512f"))) float sum(float a[], int c) {

That isn't "automatically" for me. I meant without modifying the upstream/source code with these annotations (where a human has to sit down and reason about which functions likely would benefit from these annotations). Automatically would mean the compiler is clever enough ("heuristics") that identifies which functions should be annotated with that and performs it without modifying the source. Most likely this will have to be profile-guided though. How this could be working is like this: first compile with profile guiding the sources, two times. once with -march=x86-64 and once with -march=x86-64-v3 using the extra flags "-ftree-vectorize -fopt-info-vec" and store away the resulting output.this is a debug print of the compiler that shows how/where it saw vectorizing opportunities: inflate.c:76:20: optimized: basic block part vectorized using 32 byte vectors inflate.c:76:20: optimized: basic block part vectorized using 32 byte vectors inflate.c:76:20: optimized: basic block part vectorized using 32 byte vectors In this case the vectorizing printout is "16 byte vectors" for the -march=x86-64 build, indicating that it did find an architecture sublevel specific optimisation opportunity. If many of those prints are in the same source function, and that source function is considered hot (based on profiling feedback), then the compiler would be able to use target_cloning automatically. as you can see that is quite intensive when done that way (profile guiding, which compiles twice, and then compiles twice for two architectures). It does not seem worthwhile for most of the distro code to invest that kind of effort. Greetings, Dirk