10 ms·

Lisp machines were an interesting idea. Unfortunately they were very expensive and fairly slow compared to other machines at the time.

jampekka 5y ago
I.e. worse is better.
lispm 5y ago
Actually they were not slow compared to other machines. Initially they were developed to replace minicomputers (https://en.wikipedia.org/wiki/Minicomputer https://en.wikipedia.org/wiki/Minicomputer) as machines for Lisp programmers. Instead of sharing one minicomputer having 8 MB RAM (or less) with tens or hundred users, the Lisp programmer had a Lisp Machine as a first personal workstation with GUI (1981 saw the first commercial Lisp Machine systems, before SUN, Lisa, Macs, etc.) - thus the Lisp programmer had not to compete with many other users with scarce memory availability. Often Lisp programmers had to work at night when they had a minicomputer alone - a global garbage collection would make the whole machine busy and response times for other users were impacted, up to making machines unusable for longer periods of time. When I was a student I got 30 minutes (!) CPU time for a half year course on a minicomputer (DEC10, later VAX11/780). So for a Lisp programmer their personal Lisp Machine was much faster than what he/she had before (a Lisp on a time-shared minicomputer). That was initially an investment of around $100k per programmer seat then. Later clever garbage collection systems were developed, which enabled Lisp Machines to practically use large amounts of virtual memory. For example: 40 MB physical RAM and 400 MB virtual memory. This enabled the development of large applications. Already in the early 80s, the Lisp Machine operating systems was in the range of one million lines of object-oriented Lisp code. The memory overhead of a garbage collected system increased prices compared to other machines, since RAM and disks were very expensive in the 80s. A typical Unix Lisp system was getting cheap fast, though the performance of the Lisp application might have been slower. Note that there is a huge difference between the speed of small code (a drawing routine) and whole Lisp applications (a CAD system). Running a large Lisp-based CAD system (like ICAD) at some point in time was both cheaper and faster on Unix than a Lisp Machine. But that was not initially, since the Unix machines usually had no (or only a primitive) integration of the garbage collector with the virtual memory system. Customers at that time were then already moving to Unix machines. New Lisp projects were also moving to Unix machines. For example the Crash Bandicoot games were developed on SGIs with Allegro Common Lisp. Earlier some game contents was even developed on Symbolics Lisp Machines - the software later was moved to SGIs and even later to PCs. Still a UNIX based system like a SUN could cost $10k for the Lisp license and $40k for a machine with some memory. Often users later bought additional memory to get 32MB or even 64MB. I had a Mac IIfx with 32MB RAM and Macintosh Common Lisp - my Symbolics Lisp Machine board for the Mac had 48MB RAM with 40bits and 8bit ECC. Currently a Lisp Machine emulator on a M1 Mac is roughly 1000 times faster than the hardware from 1990 which had a few MIPS (million instructions per second). The CPU of a Lisp Machine then was as fast as a 40Mhz 68040. New processor generations had then either been under development, but potential customers moved away - especially as the AI winter caused an implosion of a key market: AI software. For an article about this topic see: http://pt.withington.org/publications/LispM.html http://pt.withington.org/publications/LispM.html "The Lisp Machine: Noble Experiment Or Fabulous Failure?"
- Zelphyr 5y ago
  Do you have any recommendations for a Lisp Machine emulator for Mac?
  - lispm 5y ago
    The Interlisp-D system from Xerox/... is available: https://interlisp.org https://interlisp.org . Expect a real parallel universe. Even for a Lisp programmer this will challenge what one expects from a development system. The Symbolics system is only available as a pirated and slighty buggy software for Linux (also in VM running Linux). A better version exists, but that one is only available in limited commercial form. It's another parallel universe from 30 years ago. Most development basically stopped mid 90s.
    - jacquesm 5y ago
      In a way that's great: it will be lightning fast compared to running on the original hardware (many orders of magnitude) and it won't be affected by all the bloat that they didn't tack on during the last 30 years.
    - eschaton 5y ago
      The owner of the Symbolics IP is an unbelievable idiot for not making sure the modern emulator is distributed far and wide, with source, so people can experiment with and enhance it. That’s the only value it holds today but they seem determined to squander it by not putting it out.
      - smackeyacky 5y ago
        That would let too many people into the Lisp priesthood, can't have that kind of shenanigans going on.
      - lispm 5y ago
        I'm out
retrac 5y ago
Lisp machines weren't slow; the original CADR of the late 70s ran at around 1 MIPS on 32 bit data with up to 8 MB of RAM, making it about as fast as the VAX 780. The VAX was a large minicomputer released in 1977 and one of the fastest machines, short of a high-end mainframe, at the time. A Lisp machine also cost about as much as a VAX (but for a single user). The problem was maybe, aside from a $50,000 PC being hard to sell, that even on such generous hardware with specialized support, Lisp, particularly with the more naive compilation techniques of the 70s and early 80s, and after adding a fairly sophisticated operating environment, was still a rather hefty language.
- rjsw 5y ago
  The CADR used basically the same chips as a VAX 11/780.
bitwize 5y ago
They were fast compared to contemporary machines (minicomputers like the PDP-10). What happened was. powerful micros came out and the technology in those and in Lisp compilers for those machines eventually surpassed the LispM architecture in speed. Complacency and mismanagement at companies like Symbolics meant the LispM architecture never caught up, even when it moved to a microprocessor architecture in the 80s.
- pfdietz 5y ago
  The single most important trick I remember for Lisp on stock hardware was implementing pointers to cons cells as pointers to the next byte, and doing car/cdr by -1(reg) and 3(reg) (or 7(reg) on a 64 bit machine). This automatically traps on non-conses without any extra cost.
  - bitwize 5y ago
    Oooooh, that is "square root magic constant" levels of dirty.
    - pfdietz 5y ago
      Also, it lets you implement fixnums with zero low order bits. That is, fixnum x is implemented as x << 2 (on 32 bit machines) or x << 3 (on 64 bit machines). With this encoding, addition and subtraction that is known to produce another fixnum can be done with ordinary add/sub instructions.
  - rjsw 5y ago
    The original SPARC CPU is designed to use this tag encoding scheme, section D.4 of the V8 Architecture Manual describes how to use it.
    - pfdietz 5y ago
      Yes, that gives you flagging/trapping on arithmetic if any args are not fixnums. Aside from that, the idea works on other architectures as well.
peter303 5y ago
Special purpose CPUs ran faster than general purpose. However they had upgrade cycles of 3-5 years compared 1/2 to 1 year for commodity chips. The commodity chip almost always caught up in the meantime at a lower cost. My research group bought array processors, fine grained processor like MassPar and Thinking Machines, min-super computers like Convex, and this catch-up happened every time. LISP firmware on general CPUs caught up with custom hardware like Symbolics too. Very large customer bases like Nvidia can have annual design releases and keep up.
- zozbot234 5y ago
  > The commodity chip almost always caught up in the meantime at a lower cost. This dynamic is dead now, thanks to the slowing down of Moore's Law. We're even seeing a resurgence of special-purpose hardwired accelerators in CPU's, because "dark silicon" (i.e. the practical death of Dennard scaling) opens up a lot of opportunity for hardware blocks that are only powered up rarely in a typical workload. That's not too different from what the Lisp machines did.
- formerly_proven 5y ago
  Seems to me like Lisp was the OG "bloat language" (cf. Python, Ruby, ... today).
mark_l_watson 5y ago
My Xerox 1108 was reasonably fast, even updating it from InterLisp D to Common Lisp. Now I now live in a combination of SBCL+Emacs+Slime and also LispWorks Pro. For newbies who want to learn a Lisp, I point them to Racket.

jampekka 5y ago

I.e. worse is better.

lispm 5y ago

Actually they were not slow compared to other machines. Initially they were developed to replace minicomputers (https://en.wikipedia.org/wiki/Minicomputer https://en.wikipedia.org/wiki/Minicomputer) as machines for Lisp programmers. Instead of sharing one minicomputer having 8 MB RAM (or less) with tens or hundred users, the Lisp programmer had a Lisp Machine as a first personal workstation with GUI (1981 saw the first commercial Lisp Machine systems, before SUN, Lisa, Macs, etc.) - thus the Lisp programmer had not to compete with many other users with scarce memory availability. Often Lisp programmers had to work at night when they had a minicomputer alone - a global garbage collection would make the whole machine busy and response times for other users were impacted, up to making machines unusable for longer periods of time. When I was a student I got 30 minutes (!) CPU time for a half year course on a minicomputer (DEC10, later VAX11/780). So for a Lisp programmer their personal Lisp Machine was much faster than what he/she had before (a Lisp on a time-shared minicomputer). That was initially an investment of around $100k per programmer seat then. Later clever garbage collection systems were developed, which enabled Lisp Machines to practically use large amounts of virtual memory. For example: 40 MB physical RAM and 400 MB virtual memory. This enabled the development of large applications. Already in the early 80s, the Lisp Machine operating systems was in the range of one million lines of object-oriented Lisp code. The memory overhead of a garbage collected system increased prices compared to other machines, since RAM and disks were very expensive in the 80s. A typical Unix Lisp system was getting cheap fast, though the performance of the Lisp application might have been slower. Note that there is a huge difference between the speed of small code (a drawing routine) and whole Lisp applications (a CAD system). Running a large Lisp-based CAD system (like ICAD) at some point in time was both cheaper and faster on Unix than a Lisp Machine. But that was not initially, since the Unix machines usually had no (or only a primitive) integration of the garbage collector with the virtual memory system. Customers at that time were then already moving to Unix machines. New Lisp projects were also moving to Unix machines. For example the Crash Bandicoot games were developed on SGIs with Allegro Common Lisp. Earlier some game contents was even developed on Symbolics Lisp Machines - the software later was moved to SGIs and even later to PCs. Still a UNIX based system like a SUN could cost $10k for the Lisp license and $40k for a machine with some memory. Often users later bought additional memory to get 32MB or even 64MB. I had a Mac IIfx with 32MB RAM and Macintosh Common Lisp - my Symbolics Lisp Machine board for the Mac had 48MB RAM with 40bits and 8bit ECC. Currently a Lisp Machine emulator on a M1 Mac is roughly 1000 times faster than the hardware from 1990 which had a few MIPS (million instructions per second). The CPU of a Lisp Machine then was as fast as a 40Mhz 68040. New processor generations had then either been under development, but potential customers moved away - especially as the AI winter caused an implosion of a key market: AI software. For an article about this topic see: http://pt.withington.org/publications/LispM.html http://pt.withington.org/publications/LispM.html "The Lisp Machine: Noble Experiment Or Fabulous Failure?"

Zelphyr 5y ago
Do you have any recommendations for a Lisp Machine emulator for Mac?
- lispm 5y ago
  The Interlisp-D system from Xerox/... is available: https://interlisp.org https://interlisp.org . Expect a real parallel universe. Even for a Lisp programmer this will challenge what one expects from a development system. The Symbolics system is only available as a pirated and slighty buggy software for Linux (also in VM running Linux). A better version exists, but that one is only available in limited commercial form. It's another parallel universe from 30 years ago. Most development basically stopped mid 90s.
  - jacquesm 5y ago
    In a way that's great: it will be lightning fast compared to running on the original hardware (many orders of magnitude) and it won't be affected by all the bloat that they didn't tack on during the last 30 years.
  - eschaton 5y ago
    The owner of the Symbolics IP is an unbelievable idiot for not making sure the modern emulator is distributed far and wide, with source, so people can experiment with and enhance it. That’s the only value it holds today but they seem determined to squander it by not putting it out.
    - smackeyacky 5y ago
      That would let too many people into the Lisp priesthood, can't have that kind of shenanigans going on.
    - lispm 5y ago
      I'm out

retrac 5y ago

Lisp machines weren't slow; the original CADR of the late 70s ran at around 1 MIPS on 32 bit data with up to 8 MB of RAM, making it about as fast as the VAX 780. The VAX was a large minicomputer released in 1977 and one of the fastest machines, short of a high-end mainframe, at the time. A Lisp machine also cost about as much as a VAX (but for a single user). The problem was maybe, aside from a $50,000 PC being hard to sell, that even on such generous hardware with specialized support, Lisp, particularly with the more naive compilation techniques of the 70s and early 80s, and after adding a fairly sophisticated operating environment, was still a rather hefty language.

rjsw 5y ago
The CADR used basically the same chips as a VAX 11/780.

bitwize 5y ago

They were fast compared to contemporary machines (minicomputers like the PDP-10). What happened was. powerful micros came out and the technology in those and in Lisp compilers for those machines eventually surpassed the LispM architecture in speed. Complacency and mismanagement at companies like Symbolics meant the LispM architecture never caught up, even when it moved to a microprocessor architecture in the 80s.

pfdietz 5y ago
The single most important trick I remember for Lisp on stock hardware was implementing pointers to cons cells as pointers to the next byte, and doing car/cdr by -1(reg) and 3(reg) (or 7(reg) on a 64 bit machine). This automatically traps on non-conses without any extra cost.
- bitwize 5y ago
  Oooooh, that is "square root magic constant" levels of dirty.
  - pfdietz 5y ago
    Also, it lets you implement fixnums with zero low order bits. That is, fixnum x is implemented as x << 2 (on 32 bit machines) or x << 3 (on 64 bit machines). With this encoding, addition and subtraction that is known to produce another fixnum can be done with ordinary add/sub instructions.
- rjsw 5y ago
  The original SPARC CPU is designed to use this tag encoding scheme, section D.4 of the V8 Architecture Manual describes how to use it.
  - pfdietz 5y ago
    Yes, that gives you flagging/trapping on arithmetic if any args are not fixnums. Aside from that, the idea works on other architectures as well.

peter303 5y ago

Special purpose CPUs ran faster than general purpose. However they had upgrade cycles of 3-5 years compared 1/2 to 1 year for commodity chips. The commodity chip almost always caught up in the meantime at a lower cost. My research group bought array processors, fine grained processor like MassPar and Thinking Machines, min-super computers like Convex, and this catch-up happened every time. LISP firmware on general CPUs caught up with custom hardware like Symbolics too. Very large customer bases like Nvidia can have annual design releases and keep up.

zozbot234 5y ago
> The commodity chip almost always caught up in the meantime at a lower cost. This dynamic is dead now, thanks to the slowing down of Moore's Law. We're even seeing a resurgence of special-purpose hardwired accelerators in CPU's, because "dark silicon" (i.e. the practical death of Dennard scaling) opens up a lot of opportunity for hardware blocks that are only powered up rarely in a typical workload. That's not too different from what the Lisp machines did.
formerly_proven 5y ago
Seems to me like Lisp was the OG "bloat language" (cf. Python, Ruby, ... today).

mark_l_watson 5y ago

My Xerox 1108 was reasonably fast, even updating it from InterLisp D to Common Lisp. Now I now live in a combination of SBCL+Emacs+Slime and also LispWorks Pro. For newbies who want to learn a Lisp, I point them to Racket.