Subject: Re: Stupid Chip Q
To: None <port-i386@NetBSD.ORG>
From: Wolfgang Rupprecht <wolfgang@wsrcc.com>
List: port-i386
Date: 03/17/2001 12:26:25
> Let's see, my machine at work is a P2/450 with 256MB. My machine at home
> is a P3/666 with 128MB.
...
> "I think it's got something to do with the difference between Ultra/33 and
> Ultra/100." :-)
;-)
I'm seeing a roughly linear speed increase with clock-rate on large
builds. My old machine was a 333Mhz P-II and the one that replaced it
is a 1.1GHz T-bird. The trick in getting a linear speed increase in
builds is judicious use of the "-j" flag in make. One has to have
enough work queued up so that during a disk-i/o stall the cpu can
switch to a different ready to run parallel make. The current
defaults of "-j2" seem to queue enough work up. The idle time in top
indicates only a few percent of CPU wasted here and there.
Another data point. My mp3 lame encodes have been running for a full
cpu-week on the P-II now. (90 gigs of WAV files take a while to crunch
through.) It should take another 2-3 days to complete the crunching.
Using the default grip settings the P-II-333 can crank out mp3's at
0.6x of real-time. Using the same settings the T-bird-1100 can crank
out mp3's at 2.4x real time. So yes, at times higher clock rate does
sometimes help, but usually it just heats the house.
Now if the cdrom/ide subsystem of Asus A7V was reliable I could run
grip on the faster machine. Alas, it isn't and I can only rip 3 or 4
tracks before the cdrom driver hangs (requiring a reboot). This is
the same physical cdrom that worked flawlessly when mated with Intel
motherboards.
-wolfgang
--
Wolfgang Rupprecht <wolfgang+gnus@dailyplanet.wsrcc.com>
http://www.wsrcc.com/wolfgang/
Coming soon: GPS mapping tools for Open Systems. http://www.gnomad-mapping.com/