Greetings,

I thought this liast was about technical discussins relating to the
NetBSD kernel, or for those that make it out of 'developers' anyway. I
got up this morning, downloaded by e-mail---normally 50 messages or
so---but got 200 instead.

Whilst I don't really like to join in on the big flame wars, I can at
least post my experiences with NetBSD (Intel and ARM), FreeBSD (Intel)
and past occasional use of Linux.

1) On the Intel platform, with the Mach VM, without doubt FreeBSD is the
faster OS. In general use one doesn't notice this, but thrashing of the
disc is on average certainly less, and IO performance from the disc
cache is significantly (10-12 times) faster. Programs generally started
up quicker, too.

2) On FreeBSD the disc does go less in compiles. This may make a
significant difference, but for a big package I have difficulty
believing two thirds of the time the CPU is effectively spent idle
waiting for disc seeks on NetBSD. Maybe the real figure is more like one
third or one quarter. That said, I didn't do this benchmark so I don't
know. If this machine really is building that much and needs more buffer
cache, one could configure it in with options NBUF but that's quite
messy.

3) Developing (well, any kernel side work) for FreeBSD is an utter
nightmare for someone used to NetBSD's well structured tree. I tried to
port back and forth various drivers a while ago, and the entire
structure of the FreeBSD kernel *really* sucked. I pitty any poor sod
who has to do an architecture port with this system. Things are just all
over the places, adn I really don't like the GPL directory---at least
NetBSD has unencumbered ext2 support.

4) I have heard people (credible software developers of a highly well
known security program) comment that they have to use NetBSD as their
development system because FreeBSD didn't stay up long enough for them.
I've personally had no stability problems with either, other than
NetBSD/arm32 seems more stable than both :-) (apart from when I
periodically break it)

5) UVM has helped NetBSD an awful lot, Chuck has done a really good job.
On the ARM alone, it made mmap()ed file accesses almost twice as fast
without any pmap modifications. With pmap changes, page-ins were five
times faster (only a factor of 2-3 slower than i386 now) and forking was
twice as quick. However, FreeBSD's performance where disc is involved
still cains NetBSD's.

6) On NetBSD-current/i386, the VM gaussian page benchmarks apart from
disc-oriented IO were pretty much the same speed as
FreeBSD-current/i386. I can still assume that with large numbers of
processes, things like process exit times on FreeBSD will be faster
(read the pmaps).

7) These days, I am not so convinced that FreeBSD's better-under-load
paging is really worth writing home about. Stick more memory in---it's
dirt cheap these days. And if you want scalability for a server, won't a
machine like the ones at NASA Ames (supercomputers excluded) do better?

Anyway, hopefully my telephone bill will return back to normal soon. It
is clear to me that, while a lot of FreeBSD development has concentrated
on performance and packaging for a single architecture, NetBSD has
concentrated on portability and (for the most part) structure. SO STOP
ARGUING WHERE THERE ARE BOUND TO BE DIFFERENCES.

It's like say a big guy and a little guy standing next to each other and
saying 'Im taller than you' 'prove it' 'Im shorter than you' 'Prove
that' 'Why should I prove I'm taller than you when all that will do is
make you start weight lifting' etc. Possibly a poor comparison, but
whatever it is, please stop this bullsh?t, and let people talk about
bus-dma intelligently.

	 Neil