On Saturday, 6 January 2024 11:44:20 GMT Michael wrote: > On Wednesday, 29 November 2023 12:06:15 GMT Peter Humphreey wrote: > > On Wednesday, 29 November 2023 10:26:36 GMT Michael wrote: > > > Here's my hypothesis explaining your own observation with libreoffice. > > > As > > > a package or more finished emerging, libreoffice's turn comes up. Soon > > > libreoffice starts to execute make jobs, but any of the following may > > > apply: > > > > > > 1. There are only 4 out of 30 jobs available, because other packages are > > > already using 26, throughout your window of observation. > > > > Nope. Nothing else in progress. > > > > > 2. Libreoffice sequencing of make jobs is mostly linear with succeeding > > > make jobs waiting on output from their predecessors. > > > > That's possible, but it doesn't seem likely with such a huge code base. > > And > > why four processes, specifically and consistently? > > > > > 3. Libreoffice source code is not optimised for high parallelism - I > > > recall > > > when it was hardcoded at -j1 just a few years ago. Before this > > > restriction > > > was added, any bug reporters were advised to try again after limiting > > > make > > > to -j1. > > > > Yes, that was common to many packages for a long time because of > > incomplete > > optimisation. > > > > > Next time I'm building libreoffice on a beefier system I'll keep an eye > > > out > > > for the number of jobs to see what it gets up to. > > > > That would help, yes. > > OK, I eventually got around to it. I am observing right now LO is building > with as many as 24 jobs: > > top - 11:14:59 up 2:19, 2 users, load average: 24.46, 23.15, 9.51 > Tasks: 474 total, 25 running, 449 sleeping, 0 stopped, 0 zombie > %Cpu(s): 0.2 us, 5.6 sy, 94.0 ni, 0.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 > st > MiB Mem : 64217.1 total, 50028.6 free, 6233.7 used, 7954.9 buff/cache > MiB Swap: 0.0 total, 0.0 free, 0.0 used. 54333.4 avail Mem > > I don't use distcc. The make -j25 -l24.8 I have specified is respected.
Interesting. Thanks. > > The contribution of distcc isn't clear to me yet, as I said before. > > Sometimes it's the bee's knees; other times it might just as well not be > > there. I don't like mysteries... :) I've decided to ditch distcc altogether. During the very first build, what it grants with one hand it takes away double with the other - lots of tiny jobs all started together, but then gcc is sompiled with just two threads. That just-two happens on at least two different machines (not just separate; different). The position is no better in regular maintenance: no matter how many /make/ tasks are needed, I get just two threads compiling at a time. (I'm referring to the single-host arrangement I mentioned at the start.) I'm baffled, and I don't like it; I much prefer understanding to mystery. -- Regards, Peter.
