impressive buildworld time

Alfred Perlstein alfred at
Wed Nov 14 12:36:50 PST 2007

* Kris Kennaway <kris at> [071114 12:07] wrote:
> Jeremy Chadwick wrote:
> >On Wed, Nov 14, 2007 at 05:56:16PM +0100, Claus Guttesen wrote:
> >>Hi.
> >>
> >>Just installed a new DL360 with 8 cores at 2.33 Ghz and 8 GB ram and
> >>15K rpm sas-disks. When I installed the beta2 from cd 'make -j 9
> >>buildworld' took approx. 20 min. After a recompile of userland and
> >>kernel and switch to ULE it went down to:
> >>
> >>>>>World build completed on Wed Nov 14 17:44:08 CET 2007
> >>--------------------------------------------------------------
> >>3552.428u 1298.485s 16:15.89 497.0%     6156+1325k 25257+8117io 3368pf+0w
> >>
> >>Not very scientific and only one run but none the less my fastest
> >>buildworld time ever on FreeBSD. :-)
> >
> >Congrats!  :-)  16 minutes is really impressive...
> >
> >Our 2.13GHz C2D 6420 boxes w/ 2GB RAM can do this in about 19 minutes
> >flat (using ULE scheduler).  Disks are 7200rpm SATA300.  make -j2 used;
> >and this was RELENG_6.
> >
> >The reason I like the buildworld "benchmark" is because it's a fairly
> >real-world test and not something specific to just one piece of how
> >a machine behaves (e.g. memory benchmark, disk benchmark, CPU benchmark,
> >etc.).
> It's not a good SMP benchmark though, because large parts are entirely 
> single-threaded, and other large parts do not parallelize beyond more 
> than a couple of CPUs.  Also it is entirely incomparable between 
> different versions of the source tree.

I think an interesting SoC project would be to write something that
would be able to sort of glue together all the makefiles under
directories and teach make how to build a dep graph such that
for example all of usr.bin could be built in parallel.

We'd need some syntactic sugar to explicitly state which recurive
makes could be run in parallel and hopefully figure out a way to
avoid actually forking make(1) but instead do something like
maintain multiple copies of the state.

- Alfred Perlstein

More information about the freebsd-stable mailing list