Subject: Re: Compiler timings on varous MVII NetBSDs etc.
To: Chuck McManis <email@example.com>
From: NetBSD Bob <firstname.lastname@example.org>
Date: 01/23/2001 12:11:47
> >i just hope thie new list can help make some inroads to the performance
> >problem. too much of the PC minset is being adopted (well, CPUs and RAM are
> >so fast/cheap, who cares) when on the other hand NetBSD is trying to maintain
> >this "runs on anyt platform" ideology, but the two DO NOT MIX.
> 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.
Well, I know it compiles and runs on the MVII critters, but, you can
take a vacation and go on a round-the-world cruise, before it finishes.
The 36 hour perl compile has me a little scared, though. It only got
as far as making some of its makefiles. That is worrisome.
> What I (and I believe others as well) object to is it not building on a
> machine that in its day would support 30 - 40 interactive users and ran the
> _original_ VAX BSD.
Has anyone actually BUILT NetBSD-1.5 ON an MVII critter?
I know it builds a kernel (at least a stripped one) OK.
That is the kernel that took over 24 hours to compile.
I have not tried to build generic on it, yet.
I have not tried to make the world on it yet.
I am trying to get an original Reno up on the thing with scsi mscp
drives, but so far, no luck. I did manage to get Tahoe up with
esdi mscp drives. That was the best I could do, so far. I am
still amazed at the 45 MINUTE Tahoe kernel compile using pcc.
Why does gcc take over 24 hours?
> 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 :-)
I am not trying to be negative.... just constructively critical, so
some good will ensue therefrom. Anything that speeds up an MVII
critter will likely also speed up any VAX.
I don't think I can strip anything else out of the kernel config and
still have a runnable system. Are there 300K of ifdef's I can strip
out of the kernel code to lean it up some? I would love to try that!
> > > I have taken to compiling big things on my VS3100/M76 box at 7 VUPS as
> > > opposed to my MVII at 1 VUP. That helps some. I would really hate to
> > > have to stoop to a PeeCee to do that, although I have this 7000 class
> > > Alpha biggiemachine sitting out in the shed.....(:+}}...
> >a few of us are lucky enough to own this cool old iron. to make it useless?
> >i'd rather run VMS.
> 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.
Nah, not an alternative. VMSwhatsthenameofthecatcommandstylecommands
are not a valid option. BSD! cat du rm ls Rah, Rah, Rah!
Then again, I have thought it might be fun to resurrect a 32V suite
on an MVII critter.... hmmmmm..... that suite flies like the wind,
I have read, but it is only patched for ONE particular VAX configuration.
But, it is is our historical BSD ancestor.
If 1.5 is a huge advance, and for the sake of discussion, I will take
that point of view, then it needs a lot of optimizing on slow machines.