🚀 go-pugleaf

The point I was trying to make in my previous posting was the general one
that while lots of people worry about optimizing hardware architectures
and compilers, fewer people seem to worry about optimizing run-time libraries,
with the microVAX II 4.3BSD library apparently being a particularly bad
example.  Is it too much too ask that, for common routines (certainly printf,
the str* routines, etc), the following be done:

1) As has been suggested previously, complex routines like printf should be
optimized to run fastest in the most common cases.

2) Simple routines like strcpy should be adjusted to perform well on a
particular architecture (if the microVAX doesn't have a hardware locc
instruction, then is it too much to ask that the run-time library supplied
for the microVAX be changed not to use locc, at least in small and frequently
used routines like strcpy?).  A moderate degree of loop unrolling should be
considered.

3) Simple routines like strcpy should be recoded in assembler, at least to
the degree of having their procedure prologues simplified, and so that they
use registers which don't have to be restored.

4) In-line expansion of common (and simple) library routines should be
considered.

The above points are all fairly simple and obvious, but I suspect that
in many cases they have not been done.  My impression has been that far more
care and thought go into hardware design and compiler design than go into
run-time library design, although it may be easier (perhaps because of this!)
to squeeze an extra 10-20% performance from the system by improving the library
than by improving hardware or the compiler.

					Ehud Reiter
					reiter@harvard	(ARPA,BITNET,UUCP)

P.S. A few people have pointed out that saying a SUN-3 runs 4.2 isn't saying
much.  Sorry about that!  My SUN-3/180 runs 3.1.