numbers don't lie ...

[Danny Braniss]

[...]
> But when you perform the buildworld several times (as you
> should do when you're benchmarking properly), everything
> is already in the RAM disk.  If you instead rely on caching
> but you don't have enough RAM to hold all of src + obj +
> toolchain in RAM, then src (or at least parts of it) will
> have to be read from the physical disk again upon each
> buildworld.
> 
> By the way, the contents of the RAM disk are _not_ cached
> in RAM, so they don't waste RAM twice.  That was only a
> problem with the old vn(4)/vnconfig(8) in FreeBSD 4.
> 
> Best regards
>    Oliver

you might have a point, but this started when I asked why, two
boxes, under similar test gave idential real times, but very different
user times.

dell-2950 : make -j8 TARGET_ARCH=amd64 buildworld:
	 24m8.28s real 1h2m59.38s user 16m16.20s sys
sunfire :   make -j8 TARGET_ARCH=amd64 buildworld:
	 23m47.69s real 48m53.58s user 13m44.81s sys

and
	SUN X4100:	Dual Core AMD Opteron(tm) Processor 280 (2393.19-MHz K8-class CPU)
			one 70g sas disk (via mpt) -- x 2
	DELL 2950:	Intel(R) Xeon(TM) CPU 3.20GHz (3192.98-MHz K8-class CPU)
			4 sata disks + raid0 (via mfi) -- dual core x 2

cheers,
	danny