On Wed, 26 Nov 2003, Garance A Drosihn wrote: > > I have reformatted the numbers that Michael reported,into the following table:
>Static /bin/sh: Dynamic /bin/sh: > real 385m29.977s real 455m44.852s => 18.22% > user 111m58.508s user 113m17.807s => 1.18% > sys 93m14.450s sys 103m16.509s => 10.76% > user+sys => 5.53%
What are people doing to make buildworld so slow?
Well, I'm not *trying* to make it slow... :-)
> Here are some buildworld numbers of my own, from my system.In my case, I am running on a single Athlon MP2000, with a gig of memory. It does a buildworld without paging to disk.
I have a similar configuration, except with a single Athlon XP1600 overclocked by 146/133 and I always benchmark full makeworlds. I was unhappy when the gcc pessimizations between gcc-2.95 and gcc-3.0 increased the makeworld time from about 24 minutes to about 33 minutes. The time has since increased to about 38 minutes. The latter is cheating slightly -- I leave out the DYNAMICROOT and RESCUE mistakes and the KERBEROS non-mistake.
I keep DYNAMICROOT, RESCUE, and KERBEROS. I'm tempted to drop RESCUE just to see how much of a difference it would make.
This also shows why -j should not be used on non-SMP machines. ...so it can only possibly help on systems where unbalanced resources (mainly slow disks) give too much idle time.
I got in the habit if using -j3 back on a system where my disks were running ATA/33, even though they should have been faster. (eventually I figured out that the IDE cable had been hooked up backwards)
> Buildworld, static, with no '-j',executed /bin/sh 32,308 times.
Buildworld, static, with '-j2', executed /bin/sh 32,802 times.
Turning on accounting must have pessimized things a bit.
I did not turn on accounting. I added a simple kludge to /bin/sh so I would keep track of how often it was called. I had a benchmark of how much that slowed down buildworld, but I've deleted that now. iirc, It wasn't too much, and it would have been the same amount for all the builds that I gave numbers on.
I think you are also using a pessimized kernel (with INVARIANTS and WITNESS). makeworld times should be dominated by the gcc hog, but your sys times are almost as large as your user times.
Ugh. I forgot to check those.
Yeah, I have: INVARIANTS, INVARIANT_SUPPORT, and WITNESS. I used to have them off, but when I bought the newer Althon I turned them back on. I also have them off on my sparc. (I do keep WITNESS_SKIPSPIN, because dropping that gives me more of a penalty than I want).
> On all attempts, I started out by doing:[...skipping]> before doing the 'make' command.rm -Rf /usr/obj/usr/src/* sync ; sleep 1 ; sync ; sleep 1 ; sync
I use:
# Sometimes: export __MAKE_CONF=/etc/nonesuch
cd /wherever/src || exit 1
DESTDIR=/c/z/root \
MAKEOBJDIRPREFIX=/c/z/obj \
time -l make -s world > /tmp/world.out 2>&1
I also had some benchmarks of doing 'buildworld' over an ssh connection vs doing it at the console. Oddly enough, the ssh connection was faster in some ways and slower in others. I wonder if there is a speed-up by writing to a file instead of the console?
Rebooting doesn't affect the times much in relative terms (...), but it reduces the variance to less than a second provided the system is mostly idle.
I had done a few buildworlds before starting any of the buildworlds that I reported, and they seemed to be fairly consistent after the first one. Not "less than a second" though, I think it was a few seconds difference. Mainly I just wanted to avoid the reboots. These tests had chewed up enough of my day as it was...
> Aside: building 5.1-"security" on this same hardware tookthe following times:> real 54m10.092s [ 71.03% ]user 41m39.121s [ 24.40% ] sys 10m20.325s [ 210.69% ]
And those times *are* with 'script' running, as well as a perl-script which I use to summarize "interesting" data from the output of a buildworld. So, those times include extra overhead which is not included in the above buildworlds. That's from a 'make -j3', and obviously has a static /bin/sh.
Why so much faster? Now the times are only 20% larger than mine,
Building rescue only accounts for about 2 minutes of the 86-54 difference.
Hmm. Dunno. I had assumed it was /rescue, but I did mean to go back and get a better idea. It did seem a bit large.
It might very well be that the 5.1-"secure" build was done on a 5.1-release GENERIC kernel. Ie, without INVARIANTS, INVARIANT_SUPPORT, and WITNESS. Those numbers are from a left-over log of the build that I just happened to have around, so it was done not in as controlled a setup as the other builds.
> For those who think I'm spoiled by fast hardware, ... > ... on my sparc64 box. So I certainly am interested in > how freebsd runs on "slower HW"!
Single Athlon 1600-2000's are slow hardware :-).
I bet they beat a 300 MHz UltraSparc-IIi Processor!
-- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute or [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
