Date: Mon, 31 Mar 2003 21:06:07 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Ruslan Ermilov <ru@freebsd.org> Cc: "M. Warner Losh" <imp@bsdimp.com> Subject: Re: depend + all vs dependall Message-ID: <20030331203247.F18282@gamplex.bde.org> In-Reply-To: <20030331075623.GA82512@sunbay.com> References: <20030329.163343.53040416.imp@bsdimp.com> <20030331042628.GA65700@sunbay.com> <20030331075623.GA82512@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030331203247.F18282>