[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD/vax performance (Was: /etc/disktab on vax)
On 2012-07-03 16:30, David Brownlee wrote:
On 2 July 2012 00:01, Dave McGuire <mcguire%neurotica.com@localhost> wrote:
Very true. NetBSD is a bloated pig now compared to what it was, say,
in the 1.x days. It used to be SCREAMING fast. Of course on a big
six-core i7 machine with 32GB of RAM, it's still screaming fast. Twenty
years from now, it'll likely be a bloated pig on that six-core i7.
The difference is important, though: That consumer-grade six-core i7
machine will most definitely not be functional in twenty years, while I
know of quite a few VAX-11/750s (~30 years old) that are still running
just fine. That was one of NetBSD's earliest supported systems, and the
VERY first one, I believe, (Ragge?) for NetBSD/vax.
Let us not be too quick to de-support for the sake of de-supporting.
The maintenance and testing overhead is minimal. The latter can be ZERO
if we put it on the users of, say, VAX-11/750s, to do the testing on
those machines and report bugs, preferably with patches. (I will, once I
get my 11/750 reassembled)
We know that more recent gcc is significantly slower as it does a lot
more work and uses a lot more memory (for very little apparent benefit
certainly on vax).
If more recent versions of NetBSD are also slower then there are three
obvious (somewhat related candidates).
- gcc code generation - should be possible to test by building a older
kernel with a recent compiler and vica-versa
- kernel size - obviously less space for userland results in a less
happy system :) Stripping down a recent kernel and adding unused
drivers to an earlier, or even adding an option to restrict the amount
of usable memory should allow testing of this
- code paths - maybe there are updates to the VM system which are
function call heavy and vax unfriendly. If the first two quick tests
do not reveal anything then its down to compiling a profiling kernel
It may even be a combination of the above, but its quite likely that
one of them is a bigger factor than the others.
It would be wonderful if someone with a vax and some spare time could
try investigating these. I already have a selection of small but
random vax hacking on my plate (sysinst improvements, fixing up the
MSCP probing and increasing MAXPARTITIONS to 16 come to mind).
Come on, this month is Retrochallenge 2012 (
http://retrochallenge.org/ ), so now is a perfect excuse to spend some
time poking around with your beloven VAXen :)
Kernel size isn't the problem. I have a 4000/90 with 128MB of memory,
and it makes no difference... It's become bog slow.
gcc in itself makes a difference when you are compiling, but I suspect
the biggest cost is additional code paths all over the kernel, such as
kauth. Same for userland, where you have pam. They are all rather heavy.
I remember when we switched from sendmail to postfix. Startup time for a
VAX increased from a few seconds to over a minute to just start the mail
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Main Index |
Thread Index |