[Nix-dev] second revision of NUM_CORES patch series

[Marc Weber]

Excerpts from Eelco Dolstra's message of Tue Jun 15 22:49:43 +0200 2010:
> Hi,
> 
> On 06/13/2010 11:49 PM, Marc Weber wrote:
> 
> > Nix:
> > 
> >   pass NIX_MAX_PARALLELIZATION and NIX_TARGET_LOAD to the builder.
> >   This is currently only used the default builder running make.
> >   See patch to NixPkgs
> 
> I'm not convinced that this is a good idea.  I'm kind of afraid that this opens
> the way for all sorts of flags to influence a build externally (say, a flag to
> change the GCC optimization flags).

It's parsed by atoi. Then its ensured that the value is between 1 and
500. So no, you can't pass arbitrary optimization flags.

> >   - setup.sh: Refactor running make because -j and -l with opt-out possibility are added
> As I said before I'm much more comfortable with opt-in.
Everything is opt-in. You have to define those env vars  explicitly as
shown in the commit on nixos.

Your Nixpkgs commit
> turns off parallelism for a bunch of packages, which immediately prompts the
> question how you know that these are sufficient.
I don't. They failed. I compiled my system two times and it still boots.
Yes it is insufficient. I don't ask to enable this for everyone by
default. Its meant to be a first step in getting more experience.

The only true way figuring out whether using -j x -l x where x > 1 is
safe is running > 100 builds for each package and comparing the
resulting $out paths ignoring different hashs (or more precisely:
take them into account. But different hashs must have the same position
in the dependency tree or such). Well even that is not enough.
There was a bug report against ghc than running make -j8 failed but -j4
always worked.

So I totally agree that this patch can make things less stable.
However how much testing do we do when switching to a different gcc?
Or when compiling on Monday instead of Tuesday?

The only true way of catching arbitrary failures are implementing more
tests.

> Also, capitalized (or strangely mixed) variable names such as "NUM_CORES" and
> "NO_PARALLEL_BUILD_buildPhase" in Nix expressions are ugly.  It's also
> inconsistent to disable parallel builds by setting NUM_CORES to 1, but to
> disable them in one phase by setting "NO_PARALLEL_BUILD_..." to true.

I agree. How would you like to name them?

PARRALEL_BUILD_OPT_OUT=1
PARRALEL_BUILD_OPT_OUT_FOR_PHASE_BUILD_PHASE=1

?

Looking at the bash info page I notice that there are:

`${PARAMETER^PATTERN}'
`${PARAMETER^^PATTERN}'
`${PARAMETER,PATTERN}'
`${PARAMETER,,PATTERN}'

which do change the case.

I didn't feel to lucky about this patch either. But neither do I when
waiting for builds which could be done 4 times faster (or even faster on
other systems).

It also heavily depends on make.

Eg I didn't know what to pass to openoffice. Should I set the -P option
to MAX_PARALLELIZATION ? Should I patch their make system to read the
load? Should the nix-daemon even control who is allowed to fork and who
isn't? However this all would have been a lot more work to implement.
This patch is a compromise trying to get benefits without modifying too
much.

The perfect solution would be nix-daemon controlling processes on the fly.
Then you could change system load while builds are running.

Would you feel much better if I added "experimental" everywhere?

Marc Weber