numbers don't lie ...

[Danny Braniss]

> 
> --FCuugMFkClbJLl1L
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Tue, Sep 19, 2006 at 04:11:12PM +0400, Dmitry Morozovsky wrote:
> > On Thu, 14 Sep 2006, Oliver Fromme wrote:
> >=20
> > OF> Because buildworld is I/O-bound on systems with sufficiently
> > OF> fast processors.
> > OF>=20
> > OF> Try putting the contents of /usr/src into a RAM disk and
> > OF> repeat the benchmark.  The numbers might look a little
> > OF> different then.  Of course, you should have sufficient RAM
> > OF> in the machines -- If they're going to swap to the disks,
> > OF> your benchmark won't be happy.
> > OF>=20
> > OF> I think putting /usr/obj onto a RAM disk is _not_ necessary
> > OF> because of soft-updates, so the processes shouldn't block
> > OF> on writes.
> >=20
> > My experiments show that if you have enough memory to host radmdrive for=
> =20
> > /usr/src you'd better leave it for caching - there were no statistically
> > meaningful performance difference, at least on machines with 1G+ RAM.
> 
> Really?  My measurements show the opposite (on a system with 16GB of
> RAM).
> 
> Kris

here are a bunch of new numbers:
make: dell 2950
OS: Freebsd 6.2-PRERELEASE
cpu: XEON 3.20GHz dualcore * 2
memory: 4GB

no swap configured/used.

make buildworld -j 8:

src & obj			real		user		system		hyper
--------------------		---------	----------	---------	-----
Dell PERC 5/i RAID 0		24m17.73s	1h4m31.49s	15m47.44s	no
Dell PERC 5/i RAID 0		22m3.39s	1h38m46.84s	28m54.18s	yes
iSCSI/netapp			26m49.98s	1h4m26.77s	16m12.89s	no

src     obj
--------------------
md   Dell PERC 5/i		24m7.22s	1h4m44.94s	16m24.45	no

so, if numbers are to be believed:
	1- hypert helps in the real time, but user and system are bigger.
		allot of sweat for a very small gain.
	2- src in memory made no change.
	3- slow disc (iscsi) vs. very fast disk (PERC 5/i RAID 0) - about 1:3 speed, 
produced
	   less than 10% gain in time.

danny