openSUSE Tumbleweed Sets Great Example With x86-64-v3 HWCAPS

[coder]

Why not building *all* packages with v3 optimizations?

Because most package don't benefit. It'd just be extra work & bloat.

[oshan.wisumperuma]

Because most package don't benefit. It'd just be extra work & bloat.

Chicken egg problem. Someone should start. Glad openSUSE did that

[mangeek]

I'm confused. I though HWCAPS was a way to put multiple optimization levels into one binary, while building separate packages was sort of a recently-outdated 'legacy/heavy-handed' way to deliver optimized packages.

Also, does GCC or CLANG/LLVM offer some way to have most of the compiling effort 'conserved' between outputs for different variants? I figured at least the first few stages of compilation would be the same for a given optimization level, with CPU-specific optimizations happening after breaking things down into GIMPLE or something. If this doesn't exist, it would be a pretty good feature to be able to stack multiple targets or optimization levels in one build run and have the compiler recycle some of the early work to accomplish the builds.

[mlau]

I'm confused. I though HWCAPS was a way to put multiple optimization levels into one binary, while building separate packages was sort of a recently-outdated 'legacy/heavy-handed' way to deliver optimized packages.

It's about detecting x86 cpu features and choosing a binary library which can make use of them, at runtime. In opensuse case, they'd have to rebuild glibc for each of the vX levels, this has nothing to do with fat binaries..

[coder]

Also, does GCC or CLANG/LLVM offer some way to have most of the compiling effort 'conserved' between outputs for different variants? I figured at least the first few stages of compilation would be the same for a given optimization level, with CPU-specific optimizations happening after breaking things down into GIMPLE or something. If this doesn't exist, it would be a pretty good feature to be able to stack multiple targets or optimization levels in one build run and have the compiler recycle some of the early work to accomplish the builds.

It's a good question, and I think one that can probably be approximated by compiling at -O0 and subtracting off that time from whatever it takes to build for your chosen optimization target. I think the answer would probably be that there's not enough sharable work to justify the complexity. But, I say that as a humble downstream user of these tools.

[archkde]

I'm confused. I though HWCAPS was a way to put multiple optimization levels into one binary, while building separate packages was sort of a recently-outdated 'legacy/heavy-handed' way to deliver optimized packages.

What you're probably thinking of is function multi-versioning. HWCAPS is about deciding which one of separate shared libraries to load at runtime. While you could ship all hwcaps libraries in one package, that would be a waste of network and disk resources for (presumably already more limited) machines not supporting the higher levels.

[darkbasic]

Because most package don't benefit. It'd just be extra work & bloat.

Extra work? I'd say it's the opposite: it's much more work to test and cherry pick each single package which could potentially benefit from optimizations rather than massively rebuilding everything in an automated way. We're not talking about extreme ClearLinux-like optimizations which could regress badly, we're talking about a simple -march.

[darkbasic]

Probably similar reasons as ALHP.GO:
Buildserver resources are limited.

And so? It's still much easier to blacklist a couple of packages rather than whitelisting among thousands of them.
Electron/Chromium and a few others amount for 70% of the @world rebuild time on my Gentoo, you can bet I exclude them as well as much as I can every time I need to massively rebuild anything. When I was providing Fedora ppc64 Chromium packages I had to increase timeouts every couple of versions because the build time kept increasing :/

[cynic]

looks like many Phoronix readers think they know how to run the infrastructure of a distro like SUSE better than SUSE itself!

so much wasted talent here.

[darkbasic]

looks like many Phoronix readers think they know how to run the infrastructure of a distro like SUSE better than SUSE itself!

so much wasted talent here.

You're wrong, there are just many **opinionated** readers who want insights about the reasoning behind such decisions.
If this hurts Cynic on Phoronix I can ask my SUSE friends directly, but truth is I don't maintain my own distro anymore so I don't care that much to begin with.