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