1. the Xerox Lisp machines all used highly configurable processors which ran Lisp microcode, right back from the Alto; and by the time they got to the 1186 Daybreak it was a single chip, so a microprocessor. So to say they didn't have a Lisp microprocessor is sort of a misunderstanding. Although it's fair to say that memory was limited, and that performance was not on a par with the Symbolics or TI machines.
2. Common Lisp was very different from Interlisp, but that wasn't driven by customers.
It's worth reading Gabriel and Steele's 'The Evolution of Lisp'; neither author can be described as an Interlisp advocate, although the paper is reasonably fair. Full disclosure, I played a minor part in the European Lisp standardisation committees (under ISO WG 16) in the mid eighties, so I'm not an unbiased observer either. The conflict between European and US groups is documented (from a US perspective) in section 2.12.11 of the paper.
But essentially, I think I can say uncontroversially, the ascent of Common Lisp was highly political, and most certainly not customer driven.
Larry Massinter (et al)'s work to get Interlisp going on stock hardware is indeed a very welcome thing, but we've lost thirty years of evolution and development. Until it can address the host operating system's windowing layer, rather than running in a single window, it will remain a curiosity.
> Until it can address the host operating system's windowing layer, rather than running in a single window, it will remain a curiosity.
You're right in general. But having Medley's quirky window system and environment run in its own space is among the things I find fascinating of Medley. It's like an alien computing universe.
In former times that was the screen in front of you. With its own window manager, menus, scrolling, mouse controls, etc.
If one looks at current development environments, many of them have their own single window (with multiple subpanes and window layouts) and often a not-so-native user experience. Many cross-platform toolkits also add an additional layer. What is different here, is that the window is a new window system, where we often find in modern IDEs the IDE of subpanes, instead of subwindows/...
The Symbolics Genera UI OTOH favors multiple (mostly) full screen applications with subpanes. One switches between them via keyboard commands: select-e is the editor, select-l the listener, select-d the documentation reader, select-m the mailer, ... you get the idea.
"The central processor is a microprogrammed, 16-bit general purpose computer consisting of approximately 170 ICs of various sizes and complexity. It resides on a 10.9-inch by 16-inch printed wiring board assembly (PWBA), referred to as the Mesa Processor Board (MPB), located in slot 3 of the backplane."
"Four 2901C LSI chips that make up the core of the central processor. The 2901C is a 4-bit processor; the four chips are cascaded to provide a 16-bit processor. Supporting the 2901C are four register sets (U, RH, IB, and Link), a four-bit rotator, and four emulator registers (stackP, ibPtr, pe16, and MInt)."
Symbolics and TI had a more advanced processors: The Symbolics Ivory is a 40+8 bit specialized microprocessor. The TI MegaChip was a 32bit microprocessor for Lisp, also marketed as the first microprocessor with around 1 M transistors.
Both companies had developed chip design software in Lisp to create these microprocessors.
> But essentially, I think I can say uncontroversially, the ascent of Common Lisp was highly political, and most certainly not customer driven.
DARPA was the biggest "customer" and asked for a unified Lisp when delivering military applications. At that time many applications came with its own customized Lisp dialect. That was the reason why they invested so much money into a Common Lisp definition and later in the standard. They also invested probably close to a billion USD into hard and software projects. In the early days a research project could ask for money and when they did it in Lisp, they got a Lisp Machine for free (funded by DARPA, like the rest of the project).
"In April 1981, after a DARPA-sponsored meeting concerning the splintered Lisp community, Symbolics, the SPICE project, the NIL project, and the S-1 Lisp project joined together to define Common Lisp. "
> Until it can address the host operating system's windowing layer, rather than running in a single window, it will remain a curiosity.
In Symbolics Genera one can open multiple X11 windows and for example allocate specific activities (applications) to them. A TI explorer had a port of the interface designer, where one could interactively design Macintosh windows with the logic on the Lisp machine.
Action!, the worlds first dynamic interface builder - 1988
There certainly was a lot of mystique about Genera; I only got to play with a Symbolics machine once. But, although it was the very top end of the US East Coast Lisp machines, it was just a US East Coast Lisp machine. You edited files, you did not edit in core. You edited with a text editor, you did not edit with a structure editor. You did not have the vast range of graphical code inspection and exploration tools that we had on Interlisp (or if you did they didn't show them off), and the break inspector was just as crude and clunky as it is on a modern Common Lisp system.
My understanding is that the Symbolics machines were a lot faster than our Dandelions and Daybreaks (I never got to play with a Dorado, either...), but... I honestly don't believe they were in the same class.
Mind you, the other Lisp machine of that era that I really lusted after, the Connection Machine, I never got to play with at all, although there was one being used for something very hush-hush and defence related in one of the labs some of our machines were in.
Interlisp was about fifty years ahead of modern software development systems; Genera was forty years behind (which is fair enough, it was forty years ago).
There was a bunch of advanced things in Genera: the error handling system (-> Condition System), Flavors, CLOS, an object-oriented generic networking substrate, an ephemeral garbage collector (which vastly improved the usability of a machine with large virtual memory), support for embedding the OS into other hardware / OS combinations (like a Mac or a SUN), support for programing in C/Pascal/Fortran/Ada with a language sensitive IDE, support for color/video/3d/..., versioned source code management for files, ... Important also and mostly unique: things like the error handling system and the presentation-based UIMS was widely used in the operating system and the applications. When did you last see an operating system which was using something like the condition system (with integrated debugger and restarts) as its main error handling and gives that to the end-user? When was your TCP/IP stack written in Flavors/CLOS and could be debugged/extended on the fly? There was also a version of Genera, called Minima, that ran on embedded Lisp Machine boards.
It hasn't happened to me. I started coding in 1982; I'm still doing it. In the meantime I've started four startups (none of which succeeded - I'm a much better geek than I am a businessman - and done a couple of management jobs. But I find I still prefer writing code (and designing systems) to anything else, and I don't at all enjoy being responsible for seeing that there's enough money in the bank to pay other people's wages, so these days I'm just a contract programmer.
This is a beautiful essay, and I've really enjoyed it. However, while interesting and inspirational it doesn't all ring true. Lisps from the years before generational garbage collection might spend five percent of their time in GC; in particularly awkward cases it might rise to ten percent. I'm not saying this was desirable: it was not, particularly in interactive processes. But it was nothing like 'usually spent between a third and half of their time running the garbage collector'.
I've seen some very long GCs indeed. I'm sure I've seen fifteen minute GCs. But I've never seen GC eat a third of the processor cycles. I don't believe it.
When I was in college in the early 90s, unix systems were nonstop-paging quite often, and lisp systems would frequently pause while you were interacting with them, for nontrivial amounts of time, like multiple seconds.
And that was the 90s, after Lisp had been around for decades...
That's why my university had a site license of Allegro CL for its SUN SPARC cluster. Thus every student had access to a useful Allegro CL installation.
above the 90s were mentioned. SPARC systems shipped in the late 80s, 87something. At that time (90s) Lisp systems on stock hardware had already quite useable GCs, especially the big three commercial CL implementations on Unix (Lucid, Allegro and Lispworks). Even MCL on Mac OS had a useful ephemeral GC.
It's hard to say how many time was spent on GC in a Lisp program in the 70s. The installations were different, programs were different. How much time did a Multics Emacs written in Maclisp spend in GC? I have no idea. A macsyma running for some hours? AN early rule based system? Probably there were taken some benchmark numbers, but one would need check the literature to find them.
There are also pathological cases where Memory is mostly full and time would be spent mostly in GC, or where a lot of virtual memory is used, and much time is spent in IO paging in/out memory.
Note also that the invention of generational GCs was triggered by the availability of larger virtual memory based systems and the programs using it - available to the market outside of the original research. Before that, most of them were quite a bit smaller or very rare. Systems like the Symbolics 3600 were extremely rare and expensive. When they first shipped, GCs were copying and compacting, but not generational. Systems like that did not exist on the market before.
The claims being debated here are, as I understand them, my half-remembered claim that it was common to spend ⅓ to ½ of your execution time in the garbage collector until generational GC, and Simon Brooke's claim that actually 5% was normal and 10% was in pathologically bad cases. I think Gabriel's book shows conclusively that allocation-heavy programs could easily spend ⅓ to ½ of their time in GC, or 80% to 90% in pathological cases. But Brooke could still be right about the typical case, since when allocation is expensive, people avoid it in performance-critical code when possible.
I agree that the problem mostly went away once generational (aka ephemeral) GC was shipped. In the essay, I dated that to Lieberman and Hewitt in 1980, but in a more recent discussion with Allen Wirfs-Brock, I learned that actual generational GC didn't ship until 1986. (And Lieberman and Hewitt's paper, though submitted in 1980, wasn't published until 1983.)
Given the question of whether non-generational GC would cost more like 5% or more like 25% of your performance, the performance of generational GCs is somewhat of a false trail. Hopefully nobody was claiming generational GCs would eat double-digit fractions of your CPU time. I wasn't, at least.
See also ftp://publications.ai.mit.edu/ai-publications/pdf/AITR-1417.pdf. for an early perspective on generational GC.
Ephemeral GC btw. means something slightly different. An ephemeral GC is mostly concerned with the detection and collection of short lifetime objects in main memory.
The main problem is that architectures, implementations, actual computers, programs were so different, that you could find all kinds of numbers. Even a generational GC can get extremely busy and may not prevent from having full GCs over large virtual memory from time to time. It's also a huge difference if the GC was incremental (the work was spread over the whole compuation) or if the system stopped for much of the GC work.
But come on, I have used emacs for 25 years, and on a daily basis it stalls for annoying amounts of time while I am just doing something simple like editing a .cpp file. Today. In the year 2017.
The performance claim is from my memory of reading LISPCraft, the 1984 edition written before generational GC, where Wilensky claims that something like a third to half of your program runtime is typically spent in GC, so consing is much more expensive than it appears. But I don't have a copy of LISPCraft here, and I read it in probably 1990 or so, so I might be misremembering.
How can we verify the truth about these conflicting claims about LISP systems from the early 1980s? Maybe Gabriel's book has a more definitive answer?
(A possible confounding factor is that, at the time, the frequently-executed parts of Lisp programs were written in a more imperative style to reduce the load on the GC.)
Looking at Gabriel's 1985 book on the performance of Lisp systems (lispm posted a link in another thread: http://rpgpoet.com/Files/Timrep.pdf) we see many benchmarks using 0 GC time. His "Boyer" theorem-proving benchmark (p.133, 142/294) very commonly uses as much time in the "GC" column as in the "CPU" column (½ of the total), twice as much on SAIL (⅔ of the total), and almost never less than about half as much (⅓ of the total).
I'd like to claim that one of the four configurations of VAX Franz Lisp shone here, since it spent only about ⅐ of its total execution time in the GC. However, it spent roughly as much absolute time in the GC as the other three Franz Lisp configurations; it's just that it took 6× as long as normal to do the non-GC part of the benchmark; "normal", for context, was several times slower than SAIL. It's not clear that this counts as a performance improvement in any sense!
But, since many of his benchmarks use 0 GC time, I don't think I can justify the statement that GC just before the introduction of generational GC normally used 50% of a program's total run time; most programs did not consist primarily of evaluating tree-rewriting rules, which obviously are allocation-intensive. (Boyer isn't the worst, though. On Vaughan Pratt's Deriv symbolic differentiation benchmark, SAIL spends almost 90% of its total CPU time in the GC, though some other collectors handle it better.)
Reading through some of the other benchmarks, Franz Lisp commonly comes out rather GC-heavy, though less so than SAIL; on div2, for example, Franz spends 80% of its time in the GC. It may be significant that Wilensky was using Franz to write the book I got my original impression from.
I'm somewhat surprised that the FFT benchmark is written to use GC time, since normally I think of FFTs as not requiring any allocation at all, much less significant
numbers of allocations of separate objects...
So, in conclusion, I do think it's justifiable to say that there were significant classes of programs for which all Lisp systems continued to spend ⅓ to ½ of their time in the GC, or 80% to 90% in bad cases, right up until the introduction of generational GC shortly after Gabriel's book. But it's probably not justifiable to apply that statement generally to all Lisp programs. Your 5%–10% number sounds quite reasonable as an overall average.
> I'm somewhat surprised that the FFT benchmark is written to use GC time, since normally I think of FFTs as not requiring any allocation at all, much less significant numbers of allocations of separate objects...
Keep in mind:
a) not every machine had FP hardware, so FP instructions might be emulated in software.
b) dealing with floating point numbers may mean allocate float objects. For example not every Lisp had a direct array of floats. The array then would be a general array pointing to float objects on the heap.
c) not every compiler/interpreter was clever enough to keep floats in registers (or similar) while doing float computations.
Even today, allocating floats can be a problem in Lisp applications.
1. the Xerox Lisp machines all used highly configurable processors which ran Lisp microcode, right back from the Alto; and by the time they got to the 1186 Daybreak it was a single chip, so a microprocessor. So to say they didn't have a Lisp microprocessor is sort of a misunderstanding. Although it's fair to say that memory was limited, and that performance was not on a par with the Symbolics or TI machines.
2. Common Lisp was very different from Interlisp, but that wasn't driven by customers.
It's worth reading Gabriel and Steele's 'The Evolution of Lisp'; neither author can be described as an Interlisp advocate, although the paper is reasonably fair. Full disclosure, I played a minor part in the European Lisp standardisation committees (under ISO WG 16) in the mid eighties, so I'm not an unbiased observer either. The conflict between European and US groups is documented (from a US perspective) in section 2.12.11 of the paper.
But essentially, I think I can say uncontroversially, the ascent of Common Lisp was highly political, and most certainly not customer driven.
Larry Massinter (et al)'s work to get Interlisp going on stock hardware is indeed a very welcome thing, but we've lost thirty years of evolution and development. Until it can address the host operating system's windowing layer, rather than running in a single window, it will remain a curiosity.