Subject: Re: Compiler timings on varous MVII NetBSDs etc.
To: Matthias Buelow <firstname.lastname@example.org>
From: NetBSD Bob <email@example.com>
Date: 01/23/2001 16:14:02
> NetBSD Bob <firstname.lastname@example.org> writes:
> >Anyway, get this.... the kernel is 59528 bytes! Talk about a lean
> >and mean VAX UNIX kernel! The date stamp is March 22, 1979.
> Yeah but you don't really want to compare that to NetBSD, do you?
Yes, I do, specifically for the OT small-ram machines like the MVII
and 11/7xx crates.
> I mean, it doesn't even have virtual memory (apart from whole-process-
> swapping) and no networking either etc.
> I think it's quite clear that system software from the 70ies runs
> on a system from the 70ies quite fine, it is supposed to do so.
> Comparing 32V to NetBSD 1.5 would be, like, comparing MS-DOS 3.3
> to NT 4.0 (forgive my PCish analogy, 32V certainly is a more
> powerful and better designed system than DOS of course).
But, the machine is still the 70's machine (e.g., MVII) and not
a VAX 7000 or VAX 10000.
That is where it hurts.
I am very much of the point of view that IFF NetBSD is supposed to
support these old machines (and I think it should), then it should
NOT so overburden them that running one puts one to sleep. Compiling
a kernel really does.
Somehow, someway, we need to consider doing something that can tailor
a modern NetBSD, stripped to the bare bones, that is capable of running
comparatively well on a MVII. Right now, if 1.5 is any indicator,
we have lost touch with that capability. Right now, I am seeking out
any sort of reasonable solution to that problem. Right now, we have
no workable solutions, other than hand weeding the code down to size.
I have pared the stock code down, to an almost nothing config, and
it is still slow, big, and overburdens the MVII. Gcc totally is
overwhelming to the machine. It just won't do it anymore in 13mb
of ram on my machine, for even a perl compile. We have reached the
limiting point on this thing, in terms of any viable sort of system
usability. It will just barely keep afloat in NetBSD-1.4.3, and
in 1.5 it is taking a dive.
That is why it may be reasonable to separate out the early VAX
systems from the modern VAX systems and then tailor something to
the effect of a Classical VAX system of NetBSD just for those
machines. That is heretical, I know, but I am not yet willing
to be tied to the stake on it.