Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 31 Mar 2003 14:24:20 +0300
From:      Ruslan Ermilov <ru@freebsd.org>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        "M. Warner Losh" <imp@bsdimp.com>
Subject:   Re: depend + all vs dependall
Message-ID:  <20030331112420.GA9806@sunbay.com>
In-Reply-To: <20030331203247.F18282@gamplex.bde.org>
References:  <20030329.163343.53040416.imp@bsdimp.com> <20030331042628.GA65700@sunbay.com> <20030331165732.Q17731@gamplex.bde.org> <20030331075623.GA82512@sunbay.com> <20030331203247.F18282@gamplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--gBBFr7Ir9EOA20Yy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 31, 2003 at 09:06:07PM +1000, Bruce Evans wrote:
> On Mon, 31 Mar 2003, Ruslan Ermilov wrote:
>=20
> > 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?
>=20
> 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.
>=20
Without -j, my patch obviously has no effect on either [non-]SMP
systems, as "par-all" becomes a plain "all".  See also below.

> > 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.
>=20
> 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.
>=20
Hardly so.  My patch doesn't affect leaf directories; only
level 1 bsd.subdir.mk makefiles (*bin*/Makefile, etc.) are
affected by this parallelization.


Cheers,
--=20
Ruslan Ermilov		Sysadmin and DBA,
ru@sunbay.com		Sunbay Software AG,
ru@FreeBSD.org		FreeBSD committer,
+380.652.512.251	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age

--gBBFr7Ir9EOA20Yy
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE+iCVkUkv4P6juNwoRAtgMAJwL6H7rFkk3aQ064dg/YJe2JZSMswCfTYWb
8e4WCAS8/H+SPVSNrOkOiGw=
=u+VW
-----END PGP SIGNATURE-----

--gBBFr7Ir9EOA20Yy--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030331112420.GA9806>