Subject: Re: Compiler timings on varous MVII NetBSDs etc.
To: None <port-vax@netbsd.org>
From: Matthias Buelow <mkb@mukappabeta.de>
List: port-vax
Date: 01/23/2001 22:35:10
NetBSD Bob <nbsdbob@weedcon1.cropsci.ncsu.edu> writes:

>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.

If 1.5 runs significantly slower than 1.4 then the only constructive
approach to making it run faster, if that is the goal, is to grab
a profiler and analyze where the cycles are being spent and making
the appropriate optimizations (I'm _not_ talking about throwing
in a lot of #ifdefs -- (ab|over)using the C preprocessor is one kind
of insanity that'll haunt you to your grave if you overdo it.)

I am convinced that separating out a "VAXBSD" system and maintaining
it apart from NetBSD will serve no good (just think about all
those bugs you have to fix for yourself, possible security holes which
need to be stuffed etc. in future, which you'll get for granted, more
or less, if you continue with NetBSD).
About gcc, I'd simply say, live with it and compile things on a bigger
VAX, if that is your problem.  While gcc is pretty slow, it's runtime
memory consumption is still quite moderate, compared to other modern
compilers (for example, HP-UX (ANSI) C compiler can easily eat 20megs
or more when optimizations are enabled yet I consider it a very good
compiler (it is a bit faster than gcc, though)).
You might of course port pcc or some other compiler and add it as
a package, that would probably the best idea, so that people who need
to compile in a restrictive environment can use this one (which
probably will provide much less diagnostics and won't optimize as
well but which will at least complete the compiling job on a tight
system.)

>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.

I don't think such an approach would be worth the effort.
It would be better spent on making 1.5 faster (if possible) since
then all ports may profit from that work.

mkb