[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SUN vs Lisp machine hardware differences?



    Date: Mon, 10 Aug 87 17:05:55 PDT
    From: Malcolm Slaney <spar!malcolm@decwrl.dec.com>

    >From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
    >
    >I
    >believe a Sun could have an ephemeral GC if they came out with a new Sun
    >workstation with substantial architecture changes; but that would be
    >tantamount to building a Lisp machine, in some ways, and so that's
    >really not in the domain of this discussion.  None of their products,
    >including the new ones, have anything like this.

    Why is it necessary to have a different architecture to run emphemeral
    GC?  Aren't both Suns and Symbolics machines Turing machines? :-)

The essential part of the ephemeral garbage collector is that whenever the
paging system decides to write a modified page out to disk, it gives the
garbage collecting system a chance to look it over to determine whether to
scan the page (causing it to get page-faulted back into memory) when the the
next flip occurs. You don't really need any extra hardware to do an ephemeral
gc except the normal paging hardware that all virtual memory machines have
that detects when pages are modified. You do need cooperation between the
paging system and the garbage collector.  Even though I believe that every Sun
has enough hardware to do an ephemeral garbage collector, I don't believe sun
will ever change the operating system to allow a user program (lisp) to know
when the paging daemon is about to write pages out to disk, so one can safely
say that any "ephemeral" garbage collector that comes out for a lisp running
on a sun will not have this fundamental feature that reduces paging.

I might like to add that there are architectural features of the Lisp Machine
(all descendants of the MIT machine) that tend to make them slower than they
need to be to run pure common lisp. The extensive use of forwarding pointers
and cdr-coding, (which aren't at all needed for common lisp, but make the
system a lot nicer to use) substantially increases the amount of memory
references needed to execute programs. The tradeoff here is that the
advantages of having cdr-coding and forwarding pointers makes it possible to
do things that you can't do in common lisp and speed up some parts of common
lisp, but other things (like eq) get slowed down. Forwarding pointers and
locatives aren't in common lisp primarily because it's hard to do on stock
hardware.

In general if one limits one's discussion to common lisp, one will never find
any feature that can't be done on one machine but can on another, because
common lisp was designed so that there will be nothing that can't be done on
common kinds of computers.