[Nix-dev] Re: Parallel building support, 1st attempt

[Jeff Johnson]

On Jun 22, 2010, at 1:27 PM, Peter Simons wrote:

> Hi Jeff,
> 
>>> 1) Nix-env provides the environment variable $NIX_BUILD_CORES. The
>>>   default value is 1, which is equivalent to building with
>>>   parallelism disabled.
>> 
>> Specify the means to set the envvar please, like what the inputs to
>> the heuristic are. There are most definitely "portability" issues
>> associated with discovering #CORES and the details should be spelled
>> out.
> 
> could you please take a look at the patches? There is quite a bit of
> documentation and commentary. If that question is still unclear to you
> after reading the diffs I posted, please don't hesitate to ask for
> clarification.
> 

Patch set now reviewed.

The "portability" issue is that there isn't any clear API to
extract the number of CPUS programatically.

One is forced into attempting getconf(1) if from the CLI and the two dialects of uglix
library API's that go something like this (snipped from RPM code)

static size_t ncores(void)
{
    static size_t _ncores = 1;
    static int oneshot = 0;

    if (!oneshot) {
#if defined(HAVE_NCPU_SYSCONF)
        const long cpus = sysconf(_SC_NPROCESSORS_ONLN);
#elif defined(HAVE_NCPU_SYSCTL)
        int name[2] = { CTL_HW, HW_NCPU };
        int cpus = 0;
        size_t cpus_size = sizeof(cpus);
        if (sysctl(name, 2, &cpus, &cpus_size, NULL, 0)
         || cpus_size != sizeof(cpus))
            cpus = 0;
#endif
        if (cpus > (int)_ncores)
            _ncores = (size_t)(cpus);
        oneshot++;
    }
    return _ncores;
}

Even if you manage to extract the number of "available" CPU's,
there's the issue of how many are "online" (my words, the meanings
of "online" and "available" change as you read through "standards").

And even you manage _BOTH_ "available" and "online" programatic detection "portably",
there's additional nuances (that _COULD_ happen in some imaginary motherboard)
that the CPU's on the motherboard are differently clocked and/or flashed.

The only point I'm trying to make is that
	All heuristics to set "make -jN ..." are doomed.

Doomed because there aren't _ANY_ clear API's, or guidance, or anything
else to base a decision process on soundly.

getconf(1) and sysconf(3)/sysctl(3) are gawd awful API's to deal with "portably".

What _CAN_ (and I believe _SHOULD_ be done) is to clearly state the
inputs to your heuristics for choosing some options to make(1).

That way when some comes along with a different or better heuristic, the
mechanism for insturmenting a build recipe with "parallelism" is savable
even if the heuristics need to be scrapped.

Off hand, I do _NOT_ see where you are getting the #cpu's from in
the patch that you have posted. This line seems to be "closest" to
where the value is set

++    /* The maximum number of cores to utilize for parallel building. */
++    env["NIX_BUILD_CORES"] = (format("%d") % buildCores).str();
++

and that tells me nothing about where the value is coming from.

hth

73 de Jeff