> >Over the weekend I did some simple compiler tests on the NetBSDs
> >and other OS's I have up on my MicroVAX II critters.
> 
> Thank you Bob for investing this time, solid numbers are always better than 
> "it feels slower." !

I don't mine the play, ... it keeps me out of the bar, and chasing
VAXens (instead of Vixens!).

> >OS                           Gkermit compile time (m:s)
> >--------------------------   --------------------------
> >4.3BSD-Tahoe PCC             3:01
> >Ultrix 4.2 VAX-C             2.50
> >NetBSD-1.2 gcc 2.72          5:05
> >NetBSD-1.3 gcc 2.72.1        6:07
> >NetBSD-1.4.3 gcc 2.91        7:08
> >NetBSD-1.5 gcc 2.91          7:40
> >--------------------------   --------------------------
> 
> Try compiling it with pcc on the NetBSD 1.5 system, using 4.3 
> compatibility. I suspect you will get about 3:20 for that one.

I think I will run up pcc, gcc-1.36 (or maybe 1.42) and then test
them on NetBSD and Ultrix systems.  It will take a few days to
run up the compilers, though.

We gotta do something.  It is reaching a pitifully slow point.

>  > Clearly, the effects of bloat are beginning to overburden
>  > the lowly slower-than-1-VUP box. ... Ultrix C is well optimized
>  > for running on the VAX. gcc 2.91 sucks on slow machines.
> 
> This is my current candidate for attack. One of the issues with EGCS and 
> the GCC folks getting together is that the GCC folks brought the "PC 
> Mindset" which includes the feeling that memory is free. Anyone who has 
> written a compiler will tell you that you can burn memory to get better 
> optimizations quickly. This is what GCC seems to do most often. The impact 
> is a bigger memory footprint for the GCC image as it runs, which causes 
> swapping which causes slowness. I now run with an MFS /tmp on my build 
> machine and with TMPDIR set to /tmp to speed things up (it does by about 
> 30%) But that only works on machines where you can burn memory (and 
> explains why I want to make my 4000/90 128M :-)

Well, I can't get 128M in my MVII critter, yet.....(:+{{...
I did find a 512M ram board for a 7000 class box.  Now, if I could
only find a 7000 VAX processor board.  Anyway, I sense something has
to fix speed on the MVII (and for that matter probably also the 11/7xx
series crates, but I don't have any of those handy).  I am still 
amazed at how light and dainty feeling the NetBSD-1.2 is compared to
NetBSD-1.5.  For the sake of discussion, in a stripped kernel, with
only the 4.3BSDisms, how much late model gccism is required to get
some kind of kernel to compile?  Is there some kind of tradeoff, for
Low-end VAX use in resurrecting an early compiler?  When I am running
a gcc 1.42 or 2.58 in my SunOS crates, I don't remember them going
that creeping slow.  That kind of talk is heresy, but, if it sped
the snail along.....

For example, pcc compiles a 273K kernel in 4.3BSD.  Gcc 2.7.2
compiles a 340K kernel in NetBSD-1.2, yet, in 1.5, the kernel,
using the same exact config, is 580K in size.  40% of bloat is
not all kernel ``improvements'', and not all ``gccisms'', but
probably a mix of both.  Still, wading through that much code
probably contributes to some of the slowness.  I tried getting
lmbench to compile and run on the MVII crates, but no luck.
On the M76 box, it compiled but when run had no output.
Are there any other benchmarks that one might recommend for
some more comparative testing?  It worked fine on the 3MAX box
though.

> The last time I complained about this to the EGCS folks the answer was "but 
> PeeCees are so cheap, just buy one and cross compile!"
> Not my answer of choice.

Geesh!   Strap a VAX 11/750 onto those guys and get them to fix the
compiler, in 8M ram...... right!

Thanks

Bob