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