compilation speed with enough memory

[Charles Hedrick]

I made a comment in a previous posting that compilation and loading on
SV/AT seem incredibly slow.  I now believe that much of that was due
to insufficient memory.  At the time I wrote my posting, I had 1.6M of
memory (640K plus 1M).  I just added another 512K, to make 640K+1.5M.
This seems to have gotten rid of most of the extraneous swapping
during compilation and loading.  (As far as I can tell, by the way,
this swapping is not caused by insufficient memory, but is done to
shuffle memory in order to satisfy sbrk requests.  One would think it
would be possible to avoid this, but having not looked at the kernel,
it's hard to be sure.  Certainly you can prevent most of it in your
own large-model programs by using my malloc, which tries to minimize
the number of sbrk calls.)

Anyway, with the extra 512K of memory, things don't seem so slow.
Here are some speed comparisons: doing a full build of micrognu, I
compared SV/AT with a diskless Sun 2/50.  This is a 68010 machine
doing all file I/O across the Ethernet from an Eagle.  If you believe
Intel, a 286 (in my case, running at 10MHz) should be at least the
equivalent of a 68010, though we were always inclined to be sceptical.
Anyway, SV/AT takes about twice as long to build mg, both with and
without optmization.  I was particularly disturbed by the speed of ld
before, so I timed it separately.  It is also slower by the same
factor of 2.  Obviously some of the differences here are due to the
fact that the Sun has access to a faster disk.  (Mine is a 60msec
access time disk.)  However CPU times also differ by about a factor of
two, so that isn't all.  

Since I always thought the 68010 was significantly faster than the 286
(except for Intel benchmarks), these comparisons didn't surprise me.
To get a better idea of how SV/AT itself is doing, I tried a
comparison with MS/DOS on the same machine.  I compared times to build
a modified version of the rolodex program on SV/AT and MS/DOS, using
MSC version 4.0.  I'm not sure I believe the CPU times I get from
MS/DOS, so I'm just going to report real times.  Under SV/AT I had
nothing else going on, so these should be comparable.

	     -O         not -O
    msdos  4m7sec      3m38sec
    sv/at  7m21sec     4m41sec

(Actually on MS/DOS -O was -Os, and not -O was -Od.  MSC defaults to
-O, so you have to disable it explicitly.)  The SV/AT optimizer is
much slower than MSC's.  Without optimization, I'd bet the difference
is almost entirely due to the fact that SV/AT uses the traditional C
compiler organization into many phases: preprocessor, compiler,
optimizer, and assembler.  Pyramid found that they could speed things
up a lot by generating .o files directly, rather than calling as.
Printf isn't all that fast, and of course as has to parse your file
again, recreating the symbol table.  Presumably MSC does something
like this, since it certainly doesn't require the assembler to be
present.  Loading was actually slightly faster on SV/AT than MS/DOS
(21 sec vs 28).

So it seems that going from 1.5M to 2M of memory makes a significant
difference for compilation.  I'd say that I no longer consider the
loader to be particularly slow.  I do still think that cc is no speed
daemon, but aside from the optimizer, it's probably doing about as
well as you can do with a straight-forward Portable C Compiler type
organization.  The new generation of fast MS/DOS compilers are likely
to run rings around it.  That's because they are carefully tuned for
fast compilation, which as far as I can tell was not a serious goal
for PCC.  Looking at CPU time and real time figures, and also noting
that I don't hear the rather distinctive sound that my disk makes when
swapping, I don't think more memory would be likely to speed things up
much more, but it's always possible.