Subject: Re: Compiler timings on varous MVII NetBSDs etc.
To: NetBSD Bob <nbsdbob@weedcon1.cropsci.ncsu.edu>
From: Matt London <matt@knm.yi.org>
List: port-vax
Date: 01/22/2001 22:22:53
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On Mon, 22 Jan 2001, NetBSD Bob wrote:

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

ehehe - I'd get a telling off from my g/f if I were out at the bar chasing
vixens, I could use a beer ATM tho...
 
> >  > 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.....

Someone from the list very kindly sent me a couple of 4M cards for my
mv3100 m10e (2 in case 1 was dead) - and with 8M it's useable, but I can't
do anything serious with it running 1.5 (so I've noted). I'm not having
much success trying to get my hands on larger memory cards either. I
really wanna get my box doing something other than just sitting there
looking pretty and making clickclick cliclickclickclick noises :&)
 
> > 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!

Yeah - some of us don't have (read can't be bothered reconfiguring) any
ix86 boxen with NetBSD just to crosscompile, although I may do one day if
things carry on this way.

Something really is up if things don't improve :&/

Just out of interest - can you find something to compile that has a
fixed(ish) running time, so you can compare the efficiency of the output
from different compiler versions?

- -- Matt

- ---
E-mail:
  matt@pkl.net, matt@knm.yi.org, matt@printf.net
  matt@m-techdiagnostics.ltd.uk, matthew.london@stud.umist.ac.uk
  matt@vcd.student.utwente.nl, mattl@fnmail.com, mlondon@mail.talk-101.com
Web Page:
  http://knm.yi.org/
  http://pkl.net/~matt/

PGP Key fingerprint = 00BF 19FE D5F5 8EAD 2FD5  D102 260E 8BA7 EEE4 8D7F
PGP Key http://knm.yi.org/matt-pgp.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6bLK+Jg6Lp+7kjX8RAosZAJ9gS6t8MdXHSi6a6eSWprH1auniLwCeIwqQ
H631j5ptRAh4/txWCmxnmSM=
=yIoL
-----END PGP SIGNATURE-----