Symbolics vs stock hardware

[Mabry Tyson <TYSON@WARBUCKS.AI.SRI.COM>]

(My goodness... I was away from work for one day and I bet our mailer
that runs the SLUG mail hit an all time high for its backlog!)

Re GC.  I have recently studied several of the GC implementations out
there.  Lucid's new gc looks pretty good on paper--I'm curious how it
actually runs.  As I understand it, it does require overhead on most
SETF (or other change to non-register memory).  And, contrary to what
one person may have thought, EGCs on stock hardware don't need to scan
all of memory.  (By the way, note that Lucid's code must run on a lot
of different operating systems.  I thought another EGC on stock
hardware design I have seen looked more efficient but would require
slight modifications to each OS.  This one, I think, relieves most of
the reasons for Symbolics' trap on write to ephemeral space--but then
the Symbolics GC and storage management is more complex so I am not
sure the idea extends to cover it.)

I think Symbolics' storage management system is considerably more
flexible than conventional systems currently have (as far as I know,
but I haven't studied this area).  I doubt many of us take much
advantage of it.  I don't know how much of it could be done with
stock hardware.

Re CDR coding.  One advantage CDR coding (only reasonably available
with hardware assist) is the compaction of memory usage.  This pays back
in dividends of lower paging time.  

Re Forwarding pointers.  The incremental GC that forwarding
pointers gives you is a nice idea--however, I can't ever recall really
needing it.  I find that the dynamic GC on the Symbolics interferes so
much that we never use it.  The other uses of forwarding pointers,
as outlined by Reti, are much more useful.   I hope that stock hardware
will someday include these.  (Did the Dec-10 have these, or was that
only for certain types of indirect addressing?)

One thing that people should keep in mind in comparing performance of
machines (normal usage, not benchmarks) is the size of the working set
and the amount of memory.  The performance of Symbolics machines seems
to be very dependent on the amount of physical memory.  Watch how much
time is spent in paging.  If it seems large and you are dissatisfied with
performance, get more memory!  It really makes a difference.
(Now someone should point out the relative cost of memory and size
of working sets (in, say, switching amongst editor, compiler, and 
application).)

In my experience, the size of the swap space used on the Lispms is
quite enormous.  Does anyone out there run with 300+ megabyte swap space
sizes on SUNs, etc.?  Granted, some of the swap space has the editor,
ZMAIL, etc. in it that aren't necessary on a SUN, but I believe that when
you are almost out of room in your swap space, the amount for those
components is relatively minor.

Not so long ago, I felt that a reasonable answer to a lot of
performance problems, GC efficiencies, etc, was to have an immense
amount of memory (100+ MB).  Consider how different the GC problems would
be if you had that kind of memory!  Unfortunately, memory prices shot up
and that solution doesn't seem so reasonable right now.  (Well, I do
AI and if you give me 100+ MB of physical memory, I'll probably need
2+ GB of swap space!)

No one has mentioned color so far.  I'm not an expert, but our people
are quite happy with the color systems on the 36xx.  Their impression
of doing the same things on a SUN is that it will be quite hard.
(However, the future of color on the Ivory-based machines is unclear
and that is a significant concern to us.)  I should also point out
that what we do with the color systems and what other people may want
to do could be quite different.

Re type checking.  Seems I remember there are extra tag bits available
on Ivory that aren't used now.  I wonder if any of these will be available
for the user (eg, for user-defined types) in some way.

Re the Interlisp Virtual Machine specification.  I believe that
ENVOS sells Interlisp for the Sun based on it.  My understanding is that
the current implementation of it is relatively slow (on the order of
a Dandelion or DTiger?) on Sun-3's.  (To be fair, ENVOS is planning
on producing a faster implementation of their environment but I don't
know that it will be using that specification.)

Let me end by saying that I, too, would love to see the Symbolics
software system ported to stock hardware.  How feasible that is, I
don't know.  After all, Lucid has a lot of good people and has been
working hard to build a good Lisp for stock hardware and they aren't
up to Symbolics's level yet.  (Lest anyone not recognize the difference,
Lucid builds their Lisp for stock operating systems while the subject
under discussion is whether Symbolics could implement their OS on
stock hardware.)
-------