Subject: Re: Compiler timings on varous MVII NetBSDs etc.
To: Lord Isildur <mrfusion@umbar.vaxpower.org>
From: Brian Hechinger <wonko@entropy.tmok.com>
List: port-vax
Date: 01/23/2001 13:38:22
ok, here we go.  i'm going to try to keep this as short as possible, just
replying to various things various people have said without attribution:

> around.. I'd rather not make a total break from NetBSD, not unless we
> really cant reconcile the bloat issue (and the rc scripts! but im not
> gonna start that argument again now :) with the others. we need to keep the

i'm not recommendoing a break, i'm just looking at it as a last resort.

mmmmm, rc scripts.

> Let me say at the outset that I am not trying to put anything about
> NetBSD or any of the BSD freaks down.  My goal in all this is to

what they hell are you talking about Bob? you're the biggest freak of them all.
glad you're on our side though.  you'd be a worthy adversary.

> To the extent that raising these issues will help the BSD
> community along, I will support all that can be done to to
> help resolve these issues.

i would much rather support the NetBSD community than run away from it, but i
am willing to do what if good and right for the VAX platform and it's ability
to run a modern *nix.

> I can't handle the veddylongextendedwordinessrequirement of VMS.
> That is not in my vocabulary.  I prefer cat, du, etc.  It just
> hurts when cat becomes a megabyte in size and takes an hour to run!
>
> yeah.. to do anythign in vms you need to write an essay. :)

i am finding this out the hard way, it'll be one hell of a learning experience
though. :)

> Its a start, and remember that the counter statement to this is, "_runs_ on
> any platform does not require that it _build_ on any platform." The Linux
> folk claim to run on the Motorola Coldfire but they don't build there.

just because the linux people fall back on this small technicality of the
wording of something doesn't mean we should as well.  *I* consider the statement
"runs on any platform" to also mean builds on said platform.  who am i to make
such an interpretation of the language?  i'm the guy who /runs/ NetBSD, that's
who.

> Also let me caution against too much negativity, performance goals are just
> that, a goal that has to be reached. It is like getting the system to
> compile without errors. Bloat can be cured by #ifdef :-)

but to get the fire going, we may have to be a little extreme in the beginning.
did i ruffle your feathers?  good.  chances are you'll _do_ something instead
of talk about it. (replace the word you, with the word one, this isn't directed
at anyone in particular)

> This is fortunately an alternative, a full featured OS with decent
> performance. But again, the sky is not falling, it is clearing up. NetBSD
> 1.5 is a _huge_ advance on the VAX, it runs on lots and lots of systems.
> Getting it to run faster is an analysis game with well known rules.

but wouldn't you rather start from somewhere like 1.4 where the trip to 
optimized seems that it will be shorter?  backporting the new hardware support
from 1.5 to 1.4 would probably be trivial at worst, so that's not a very good
rationale.

> this is a big one. these machines are no sluggish toys- they were the
> seriousest of serious hardware for a long time, and theres no fundamental

what do you mean were?  we still run several 6000 series machines here.  i
don't see them going away any time soon either as they are doing a stand up
job, and are far lass trouble than any of the other hardware we have here (and
i include the SUN hardware in that list, pretty significant coming from a SUN
bigot)

> some newer VAXen arent supported in any older versionsmeans we have to
> run 1.5 in some cases, but its not that it is 1.5 that makes it great,
> but the hardware support- the fact that it is 1.5 is tolerated only cause
> otherwise we'd be running vms on these beasties :)
> I'd much rather be runnign 1.4 than 1.5 (and i do still run 1.4)

so let's backport hardware to 1.4 and do the Classic VAX branch.  the more
i think about this, the more it seems reasonable.  does the vax port need USB
support, uhm, i'm gonna have to say no.  and so on and so forth.  time doesn't
need to be spent making all the new gadgets work on port-vax since the hardware
isn't ever gonna use (or even able to use) any of this new junk that keeps
coming out.  maybe i'm taking the wrong view (#ifdef out the unsupported code,
being the way ti's done now?) but i think the point is more important than the
application. (i hope that makes sense, i can't seem to get it from my brain
into english, pretty sad considering english is the only language i speak)

> I think the 1.5 bloat will begin to be more and more visible to other ports 
> too.  (maybe the m68k-based ones ?)

of all of them, i think the m68k ports are very well the next to show signs of
bloat since they are in the same "performance class" as the VAXen and low end
MIPS.

i want to continue to use NetBSD as my operating system, on all my machines
that don't run Solaris, and i've got several different platforms here, so
obviously my threat of breaking off into VaxBSD is mearly an empty one.  but
i think the point is, that something needs to be done.  the good thing, is that
Bob (bless his BSD heart) has really started us all on the right path to doing
the Good Deed(TM)

cheers,

-brian