Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: [RFC] RESTRICT=parallel for builds that can't be executed in parallel
Date: Wed, 14 Apr 2010 13:03:51
In Reply to: Re: [gentoo-dev] [RFC] RESTRICT=parallel for builds that can't be executed in parallel by Justin
1 Justin posted on Wed, 14 Apr 2010 08:46:15 +0200 as excerpted:
3 > On 14/04/10 04:12, Zac Medico wrote:
4 >> Hi everyone,
5 >>
6 >> Should we add a RESTRICT=parallel value for ebuilds that can't be built
7 >> at the same time as other ebuilds? Brian says we need it for things
8 >> like xorg-server which calls eselect opengl.
9 >
10 > There is at least one other example which benefits from singlular build,
11 > atlas libs. They run a benchmark suite to create platform specific
12 > headers, which is heavily influenced by the system load. So having
13 > RESTRICT=parallel would make the emerge more reliable.
15 sci-libs/blas-atlas (and perhaps lapack-atlas, etc, too), right?
16 "Automatically tuned..."
18 Wow! Yeah, that sounds like a reasonable example. Sort of like the
19 kernel does for md/RAID-5 and 6 at boot, I'd guess, choosing the fastest
20 algorithm on the platform, only they're doing it during system runtime
21 when who /knows/ what else is running! Having a second highly
22 parallelizable (MAKEOPTS version) build go from config to build and its
23 load go from say .8 to 8. in the middle of those benchmarks /could/ screw
24 things up "just a little!"
26 Thanks. That's just the sort of additional practical example I was asking
27 for to try to get my mind around this. Excellent example as, unlike the
28 various xorg/mesa/drivers thing, it's pretty hard to argue "just code
29 around it", for this one. The only technical way out of it here would
30 seem to be to change the build-and-benchmark strategy itself, which would
31 rather defeat the "automatically tuned" bit entirely.
33 BTW, gcc seems to do some stage output comparing in its bootstrap
34 process. Is that all absolute code correctness, or is there some
35 performance benchmarking there that could benefit from this as well?
37 --
38 Duncan - List replies preferred. No HTML msgs.
39 "Every nonfree program has a lord, a master --
40 and if you use the program, he is your master." Richard Stallman