brettviren / worch

Let the orchestration waf through the suite.
5 stars 3 forks source link

Default parallelism level in art config #42

Open drbenmorgan opened 10 years ago

drbenmorgan commented 10 years ago

I've started up the art build as described here:

https://github.com/brettviren/worch/blob/master/doc/fnal.org

So far so good, but I have noticed some excessive parallelism in builds - I'm running on a quad core Linux box, but I'm seeing up to 20 concurrent invocations of the compiler. This seems to be coming from the gcc_fnalbuilder step. I've tried limiting the waf jobs to 4, but this has no effect. Could there be a "make -jN" with a large N hidden in the FNAL scripts?

Not a critical problem, but does cause the load to skyrocket, so might not be giving the most efficient build.

brettviren commented 10 years ago

Yes, there is a hard-coded "make -j20" in the Fermilab build script for GCC. On the other hand, the scripts for Geant4, ROOT or art itself do a serial make but would benefit from some parallelism (although I have failed to build ROOT with parallel make). I know this issue is on the radar of the script maintainers but I'll bring it up again.

Note, there is an inherent potential collision between waf-level and make-level parallel running. It is possible that you get "lucky" and have N waf threads times M make threads which would be bad if the configuration sets N = M = NCPU. But in tests where worch can dictate both these numbers it hasn't, in practice, been much of a problem. The amount of packages not running parallel-make and the amount of dependency constraints at the waf-level, which force a certain amount of serialism, means that I rarely kept all CPUs running even with just 4 cores. When I allowed the build to overload the amount of available CPUs the overall build times did not suffer that much (at kind of the 10% level). Although, surely this depends on the level of overloading.