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? "Automatically tuned..." 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
