depend + all vs dependall

[Bruce Evans]

On Mon, 31 Mar 2003, Ruslan Ermilov wrote:

> On Mon, Mar 31, 2003 at 05:04:42PM +1000, Bruce Evans wrote:
> > On Mon, 31 Mar 2003, Ruslan Ermilov wrote:
> > > ...
> > > Also, your test is not honest because original Makefile.inc1
> > > did not parallelize the "all" stage of "buildworld", by not
> > > implementing par-all.  Last time I tried par-all, it saved
> > > me 16% of time from the -j8 buildworld:
> > >
> > > 26m8.74s real           26m13.08s user          11m9.70s sys (old)
> > > 21m48.52s real          26m20.60s user          11m4.95s sys (new)
> > >
> > > Attached is the message with the patch.  It has some Russian,
> > > but also includes a patch.  Note that par-all only parallelizes
> > > top-level bsd.subdir.mk makefiles, as we depend on the ordering
> > > of traversing SUBDIRs in a few places.  The plan is to drop
> > > this assumption in places that don't need this ordering.
> >
> > Please benchmark mainly for the usual case of non-SMP :-).
> >
> You mean for the non-SMP case but with -j?

Mainly the non-SMP case without -j.  -j is currently too broken to give
anything except pessimizations for the non-SMP case, and it would not be
clear if optimizations for it are just side effects of not going near
the bug.  After it is fixed then it will double the number of combinations
to test.

> On a Celeron 800 system with ATA100 disk using -j4 -DNOCLEAN buildworld
> of RELENG_4 a friend reported the following times:
>
> Without patch		With patch
> real    69m43.271s	69m26.722s
> user    38m22.009s	38m19.384s
> sys     10m45.273s	10m41.596s
>
> Further reports show that on single-CPU systems with large CPU
> cache the real time win was near what I have reported for 2-CPU
> box, and it had no effect on small cache single-CPU systems and
> -j builds.

I think I understand why it often makes little difference: it saves
a tree traversal, but costs an extra make process for each leaf
directory.

Bruce