On Tue, Jan 23, 2001 at 10:48:18AM -0800, Matt Thomas wrote:
> At 01:32 PM 1/23/2001 -0500, Thor Lancelot Simon wrote:
> >pcc is a *terrible* compiler.  If we shipped pcc instead of gcc (not that
> >we can, due to licensing; SCO owns the code) you'd be complaining about
> >how slowly everything *else* on your system ran, instead of how slowly
> >the compiler ran.  Your system may be slow now, but if you rebuilt the
> >world with pcc, it would be a LOT WORSE.
> 
> pcc does sucks pond water.  Compilation time should not be what we are
> comparing, but execution time.
> 
> >Gcc is not a very good compiler.  On the other hand, it's by far the best
> >compiler available for the VAX.  It could probably be tweaked to be better,
> >but I don't know how _much_ better.
> 
> I can answer that.  I've been working on GCC's code generation for VAX as
> part of the ELF work.  I've been reducing the number of instruction by
> about 4-8% and the code size by the same.  I've been adding optimizations
> and peepholes to speedup and reduce code size.  In -current, I've tweaked
> vax/include/macros.h to make many of the inlines more efficient.

Go Matt!  This is, IMHO, the sort of thing that port-vax should be doing
to improve the VAX port.  The compiler touches absolutely everything in
the system, so improving it's output will produce improvements across
the board, including compile times.

There are other parts that affect everything or nearly everything in the
system, and they can be optimized a bit as well.  UVM is measurably
better than the old VM system. I don't have numbers, but I wouldn't be
surprised to find a sizable percentage of the "kernel bloat" came from
the switch to UVM.  Is there some way that the UVM system can be better
optimized for the VAX?  Are there macros or inlines that could be added
such that they are transparent to other ports, but translate to a machdep'd
function for VAX to produce improvements?

Now take that idea to the kernel.  We need to ask ourselves, are there
macros that can be added to parts of the kernel, such as the branch
prediction for conditionals, that would help the compiler use the
features of the processor to its fullest advantage?  Can we do this in a
way that would allow a similar improvement in other ports through a
machine dependent inline?

This is where tech-perform should come in.

Tech-perform should have members from all ports bringing their knowledge
and expertise with specific platforms and subsystems together to make
sure the improvements are as machine independent as possible and don't
injure one port to speed up another.  It would, after all, not do to add
an improvement that takes advantage of the VAX's vector abilities if it
meant at the same time invalidating the processor cache on an x86.
Where can we take advantage of MMX or AltiVec?  How can we do it such
that the code doesn't care what kind of vector unit you have because
it'll translate down to the right one during the build?  I believe this
was the idea for the list from the start, but the first posts to it seem
to be losing that focus already.

NetBSD, both the system and the community around it, is unique in that
it has the tools, the talent and the opportunity to make a system that
performs well with a wide range of hardware, and because it does support
such a spread to do it in a way that works with the concepts of computer
science.  Great strides can be made by doing so, strides that will
improve not only the older platforms we work so diligently to keep
useful, but also the systems we won't see for another ten or twenty
years.

In short, attack the big things that affect everyone.  Attack them from
the point of view of features and abilities for all platforms so that
NetBSD as a whole matures into an OS that not only runs on anything but
also runs circles around anything else, anywhere else.

jf
-- 
John Franklin
franklin@elfie.org
ICBM: 35°48'19"N 78°46'39"W