Originally posted by darkbasic
View Post
Announcement
Collapse
No announcement yet.
openSUSE Tumbleweed Sets Great Example With x86-64-v3 HWCAPS
Collapse
X
-
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.Last edited by mangeek; 07 March 2023, 12:31 AM.
- Likes 1
Comment
-
Originally posted by mangeek View PostI'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.Last edited by mlau; 07 March 2023, 02:38 AM.
- Likes 2
Comment
-
Originally posted by mangeek View PostAlso, 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.
Comment
-
Originally posted by mangeek View PostI'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.
Comment
-
Originally posted by coder View PostBecause most package don't benefit. It'd just be extra work & bloat.## VGA ##
AMD: X1950XTX, HD3870, HD5870
Intel: GMA45, HD3000 (Core i5 2500K)
Comment
-
Originally posted by Lycanthropist View Post
Probably similar reasons as ALHP.GO:
Buildserver resources are limited.
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 :/## VGA ##
AMD: X1950XTX, HD3870, HD5870
Intel: GMA45, HD3000 (Core i5 2500K)
Comment
-
Originally posted by cynic View Postlooks 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.
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.## VGA ##
AMD: X1950XTX, HD3870, HD5870
Intel: GMA45, HD3000 (Core i5 2500K)
- Likes 2
Comment
Comment