I have sometimes mused over a though about speed, and thought I'd share it
with you and see what you think.

While building stuff on my 8650, I've sometimes noticed that system time
can hover around 50% when running build.sh, and in my eyes that don't look
to good. NetBSD nowadays cache rather aggressively, and have a unified
vm, and so on. All this is very nice on machines with lots of memory,
*and* lots of CPU cycles. If you have a rather slow machine, I think
agressive caching can actually hurt.
The reason is that agressive caching means that the CPU will be doing a
lot of memory to memory copying, instead of using the controller DMA. On a
slow machine this means that CPU cycles that could have been used by
another process is instead sacrificed doing this copying. And relatively
speaking, disks are faster on old VAXen, compared to CPU cycle times.

In a machine where you have plenty of cycles compared to disk I/O, have
hardware to copy memory blocks without involving the CPU, or on a system
where you are alone (well, few programs running concurrently anyway),
burning the CPU to cache the disk is fine. On a VAX, it might not be that
fine. Often used stuff, especially meta information, makes very much sense
to cache, but normal files might not be that good.

Now, if someone says that the disk caching is zero copy stuff, I'll have
to reconsider, otherwise it might be worth discussing a bit more.

And I cannot understand why system time would be so high unless it's the
disk caching at work. Peak on the 8650 (checking with top) have been
around 75% system time, and average when running build.sh is perhaps 15%.

gcc is bad, I'll admit, but it's perhaps not the only culprit. Just
running make, which finds out there is nothing to do takes hours (well,
days actually).

	Johnny

Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt@update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol