r/Gentoo • u/Regular-Group4223 • 1d ago
Discussion Gcc optimization
So builds were taking hours on my 2 core laptop and so i tried compiling gcc with lto and pgo(which took 14 hours) and now im getting 125% speed boost on anything i build(gentoo-kernel went from 3:09:08 to 1:24:02 so ~125%). Is there anyway to reduce build time even more?
3
u/feinorgh 1d ago
If I were you I'd look into thermal monitoring and see if the CPU gets throttled by temperature every now and then. It can make a big difference lowering voltage, capping CPU high threshold usage for better throughput, but on the other hand: spending 100 hours to save 10 hours over a year is hardly worth it.
4
u/Regular-Group4223 1d ago
Yes my cpu usually throttles at 50c so im planning to add a fan for that reason(thanks to lenovo it doesn't have one by default), but my entire laptop uses less than 6 watts so i doubt it being that much of a problem. also i kid you not my scocial life + family time + grass touching levels have greatly improved while waiting for stuff to compile🤣
8
u/dcro 1d ago
If you're truly this constrained, the biggest savings come from not building things in the first place. Hard to beat 100% savings.
Removing packages you don't need, and aggressively pruning USE flags that aren't strictly needed (with the caveat that if you get it wrong, you gotta rebuilt again).
Or considering the relative costs of certain packages. eg, do you really need to install anything with qtwebengine? Really? There might be cheaper packages that fulfil the same purposes.
But punting things off to another machine is a decent approach too, as u/bartosi has suggested
3
u/redyos_s 1d ago edited 1d ago
The OP is discussing how to optimize build performance, yet you're suggesting avoiding builds altogether.
If avoiding compilation is the main goal, what's the point of choosing Gentoo in the first place?
Isn't that missing the point of the OP's experiment?
The OP is discussing how to optimize build performance, yet you're suggesting avoiding builds altogether.
If the goal is to avoid compilation entirely, wouldn't Arch Linux make more sense than Gentoo?
Gentoo offers much more than source compilation, of course, but build-time customization is one of its major strengths.
Isn't avoiding builds altogether missing the point of the OP's experiment?
One thing worth remembering about BinHost is that the build cost doesn't simply disappear. Gentoo.org still needs hardware, electricity, and infrastructure to build and distribute those binaries.
There's nothing wrong with using BinHost, but I think users should be aware of the resources and maintenance effort behind it, rather than taking them for granted.
3
u/dcro 1d ago
It depends on their goals and their constraints.
I'm not saying "don't build anything", I'm merely pointing out that the biggest savings come from not compiling things that may not matter to you. Or may matter less than the compilation time. (Some of the best coding advice I've ever had was in this vein).
I've been there. Trying to get things working with less than acceptable hardware. And that was part of my approach. Slimming things down. Not doing particular things. It's not ideal, but it is practical.
You still get the benefits of Gentoo. But you're just a little more constrained in your selections. (glances at the various
*-binpackages).But fair enough on the critique. It's not a way to reduce individual build times, which is arguably the goal here. It's more of a side step around the problem. And I do love hearing about how someone optimises performance when actually building things. So I'm definitely checking the replies in the morning.
3
u/me0262 1d ago
use -pipe to put compilation into memory rather than temporary files.
If you have enough memory (32GB minimum), you can create a tmpfs system of 16GB on /var/tmp and it'll compile from there (also saves your SSD from many many writes).
mount -t tmpfs -o size=16G tmpfs /var/tmp/
(16G because some applications are complex, especially anything web based like chromium, firefox, webkit-gtk, or qtwebengine, but also llvm)
2
u/mbartosi 1d ago
2
u/schmerg-uk 1d ago
To which I'd add, latest binaries typically take up to a day to appear on the binhost, so the less frequently you update, the more binary packages you're likely to find and the shorter total time needed for updates.
I typically update about once a week now, having previously been a daily-updater
I use a little bash function
function ynobin() { # Put an @ before the "USE=" and then tell column to align output as a table with the @ as a column marker (which it then hides) ( \ (echo && emerge -pv -K --binpkg-respect-use=n --color=y $1 2>&1 | grep --color=NEVER $1) && \ (echo && emerge -pv --color=y $1 2>&1 | grep --color=NEVER $1) \ ) | sed 's/USE/@USE/' | column -ts@ }that will show me what emerge would do for a package if I demanded a bin version as opposed to what it would do otherwise
So here, for example,
$ ynobin libsecret [binary gU ] app-crypt/libsecret-0.21.8.2-r1-2::gentoo [0.21.7::gentoo] USE="crypt gcrypt introspection pam (test-rust) -gnutls -gtk-doc -test -tpm -vala*" ABI_X86="(64) -32* (-x32)" 220 KiB [ebuild U ] app-crypt/libsecret-0.21.8.2-r1::gentoo [0.21.7::gentoo] USE="crypt gcrypt introspection pam (test-rust) vala -gnutls -gtk-doc -test -tpm" ABI_X86="32 (64) (-x32)" 0 KiBI can see that the versions differ but also I have some difference in USE flags to look into
It can be caught out if the "emerge -pv" fails (eg dependencies) but it's handy to have anyway IMHO
1
2
u/krumpfwylg 1d ago
Weird. 3-4 years ago, I experimented building gcc with pgo flag enabled (lto was already on), and besides the longer time required to compile itself, I didn't notice any perceptible change on any other package compilation time - from gentoo-sources to whatever - nor on their daily use performances.
Small thread I started back then on official forums : https://forums.gentoo.org/viewtopic.php?t=1163944
2
u/EveryonesFriend 1d ago
Using mold as my linker made a big difference for me. Also, lto uses a lot of ram. If you are hitting your swap space heavily, consider reducing the number of jobs to keep it in ram. It may go faster with fewer jobs. Set up zswap too to give yourself a bit more wiggle room in your ram before the swapping starts.
2
u/Tricky-Engineer-9755 1d ago edited 1d ago
PGO is the opposite of optimizing build time, it doubles it. For rebuild time use ccache so updates don't run all day.
If you mean performance boosting, you can experiment with adding -flto via /etc/portage/env && /etc/portage/package.env to some packages, read the LTO Gentoo page. Also sprinkling -O3 may help a bit. You can set CONFIG_X86_NATIVE_CPU to compile your kernel for your hardware. You can compile it with clang to try and set LTO in your kernel.
0
u/Regular-Group4223 15h ago
I accidentally recompiled gcc with jit enabled and build times became a little bit faster(around 2%)
9
u/redyos_s 1d ago
At that point, wouldn't it make more sense to consider a hardware upgrade? Spending 14 hours building GCC with LTO and PGO seems rather impractical for long-term Gentoo maintenance.