[Toybox] toybox build first-world problems

[enh]

On Mon, Mar 6, 2023 at 8:52 AM Rob Landley <rob at landley.net> wrote:
>
> On 3/5/23 13:01, Rob Landley wrote:
> > 8-core mac is a new use case. It probably needs to fall back to the old pre-n
> > behavior (like 80% efficiency on average on my 4x processor laptop I'd guess?)
> > instead just not using -n when "wait -n" errors (which has side effects).
>
> I reimplemented the old round-robin $PID wait as the fallback when there's no
> -n. And it's more like 90% efficiency in my testing on my laptop: you can see
> the tops of the CPU usage bars flutter a bit vs solid in the other one, but it
> keeps them all mostly busy. (I used to compensate by launching N+1 processes,
> but didn't put that part back. Not likely to make a measurable difference on >8
> processors anyway.)

yeah, that's much better. the 128-core build is down to about 2s (with
no "dribble" of dots after the first 128), and the "configure" part is
now very slightly larger than the compile part even for a clean build.
(obviously the "configure" part is almost all of the time for an
_incremental_ build on any machine.)

the macOS build is down to 7s, which is a huge improvement. thanks!

(is there a reason this stuff isn't just `| xargs -P` though? macOS'
xargs does support -P, as does toybox's. might be worth a comment if
so.)

(and why does scripts/genconfig.sh take so much time if the .config
file hasn't changed? should genconfig() have a `-nt` test?)

> >> this is a lot less noticeable when you have 128 cores,
> >> because that's "most of defconfig" anyway. but when you only [world's
> >> tiniest violin] have 10 cores, it's really noticeable [even without
> >> that patch] the first 10 dots appear instantaneously, but the
> >> remaining ones appear one-by-one [which is what made me ask ps "what's
> >> actually going on?"]. there's basically just one compile job running
> >> at any given time after the first batch on the Mac. it's not _quite_
> >> serial though, because on the 128-core box i do see ~4 cc jobs at a
> >> time after the initial 128 job goldrush.
> >
> > And that's a separate issue. I admit I have 4 cores here so wouldn't notice a
> > limit of more than that, but... what?
>
> Did commit dd56ea086435 address this part too, or is there more to do?
>
> Rob