[comp.sys.xerox] The demise of Envos and Lucid on a Sun3/50

jonl@LUCID.COM (Jon L White) (04/28/89)

re: Actually, Medley was a whole lot better behaved than Lucid was on a 3.
    A 3/50 with 8Meg of memory was about the speed of an 86, with the
    added advantage that it actually ran on the 50, and didn't crash it
    randomly as opposed to Lucid.  

What you say about "crashing" was pretty much true in the early days of
the Sun3/50.  There were apparently irreconcible problems with running
large images on the 3/50.  We discovered some gaps in the OS interface 
of the /50 that seemed to be causing the problem with Lucid Common Lisp;
indeed, Lucid's Lisp ran reasonably well on a 3/60 without the "crashing" 
problem.  Of course, we reported these conditions to Sun [just as we had 
reported the infamous problem of the stack-overflow signal being signalled
normally by pushing it on the stack].  But I'm not sure if Sun publicly 
acknowleded the problem; in the past, they would treat these OS bugs that 
tripped up big Lisp programs [as opposed to small C programs] as "an 
incompatibility between Unix and Lisp."

Please note that shortly after that "discovery", Sun stopped selling
the 3/50, and has concentrated on 3/60, 3/110, and larger machines.
I don't claim that Lisp performance was the _major_ problem of the 3/50.
I am aware that many Universities had purchased bulk quantities of 3/50's 
hoping to gain a cheap entry into the Unix Workstation experience.  For 
many who bought in that way, it's been an experience they'd rather forget.


Of course, Interlisp-D style memory management is much more suited
to the "small memory" configuration.  Ron Fisher's analysis sent out
some months ago to this mailing list was fairly accurate.  However,
the "large, heavy footprint" of Lucid Common Lisp is not the only
way to use it.  The 3.0 release -- shipping on Suns since last Sept?
-- contains the "Small, Fast Compiler", or SFC for short.  The major
difficulty in using Lucid Common Lisp on small-memory workstations
was the large amount of resources consumed by the optimizing compiler.
So we bundled in a "quick-and-dirty" option, which typically runs in
1/5 the time and 1/5 the working set space of the highly optimizing 
compiler.  The image is still large by comparison to, say, Medely; 
but the goal was not to downsize Common Lisp for "personal computer" 
sized machines.  Rather it was simply to make it usable on the smaller 
(and fairly common) Suns.  After all, I remember the days when a
full Interlisp on a D machine ran reasonably well in 1.5MB!

But Lucid's product is a moving target.  Just as declarations
for "semi-strong typing" were an answer to the question of how
to achieve speed in Lisp comparable to that of Foratran and C,
so there will be declarations for separating out the delivery
end of a product from it's development environment.  One can 
expect to see some reasonably small images cranked out for
small applications -- ones that would run perfectly well on
a 4MB machine.  

On the other hand, I would expect to see, shortly, almost as many 
32MB workstations delivered as there have been Sun3/50's shipped in 
the past.  Don't hold your breath; but it is happening.


-- JonL --