6 ms·

A Lisp Machine today would be an anachronism. Hardware type tagging could be useful. But list efficiency and manipulation would likely be futile. Today, cach

A Lisp Machine today would be an anachronism. Hardware type tagging could be useful. But list efficiency and manipulation would likely be futile. Today, cache is king. Which means, linked lists are out. CAR/CDR? Let's not. The glory days were not that glorious. There are stories out there of runaway garbage collections, that grinded on for days. Today you get garbage collections in your web browser that would embarrass any Lisp Machine ever built.

duncan_bayne 11y ago
Sure. I don't think anyone is arguing that we should fire up a Symbolics machine in 2015 and try to get work done on it. Rather, it's the spirit of the machines - inspectable and programmable from the ground up - that's worth preserving.
- lectrick 11y ago
  > inspectable and programmable from the ground up - that's worth preserving. This is what made me curious about the Smalltalk-based Squeak VM http://squeak.org/ http://squeak.org/. Its entire interface and stack was inspectable and manipulatable in real time. In practice it seemed a little buggy, though. If you installed Squeak programs too willy-nilly, pretty soon you'd get errors due to incompatibilities.
digi_owl 11y ago
And you can still have GC problem. Google ran into that with their Dalvik VM in Android.
kazinator 11y ago
> Which means, linked lists are out. CAR/CDR? Let's not. Data structures are dictated by the requirements of what you're doing, not the machine. Linked lists are out? The C middleware that runs everything is full of "struct foo { struct foo * next; int other_field ... }". Linked lists benefit from caching, like other kinds of data. > Today you get garbage collections in your web browser that would embarrass any Lisp Machine ever built. The garbage collection in your web browser is complete, utter garbage compared to what Lisp people were doing 30-40 years ago. Sorry! (I will add to this comment later; I have to go to Task Manager and kill the web browser.)
- physguy1123 11y ago
  > The garbage collection in your web browser is complete, utter garbage compared to what Lisp people were doing 30-40 years ago. Sorry! Can you back that statement up? GC has advanced heavily over the years (and still is).The first paper on generational GC was published in 1984, and I would imagine that it has drastically improved since then. I don't think that generational GC even landed in SBCL until sometime around 2005. Without anything to back that up, your post just sounds like Lisp fanboyism.
  - gnaritas 11y ago
    Not the OP, but LISP machines had hardware incremental GC, I'd say GC in the hardware is pretty bad ass and was probably more predictable than modern software based GC.
  - lispm 11y ago
    You could read the chapters on memory management and GC in the Symbolics Genera 8 manuals: areas, generations, resources, ephemeral GC, generational copying GC, full GC, ... http://bitsavers.informatik.uni-stuttgart.de/pdf/symbolics/software/genera_8/Internals.pdf http://bitsavers.informatik.uni-stuttgart.de/pdf/symbolics/s...
- kristianp 11y ago
  "The C middleware that runs everything is full of "struct foo { struct foo * next; int other_field ... }"." C datastructures most commonly used are Array of structs, Trees and Hashes. Linked lists are not commonly used I imagine. I don't have any stats to back that up though, neither did you.
  - agumonkey 11y ago
    It's still interesting to see the duality in both paradigms. Lisp goes for genericity with the cons based list, while "static languages" reimplements them under encapsulated names. I'm not trying to compare per se, just to look at both side of the coin.
prestonbriggs 11y ago
Cdr-coding is a fine way to take advantage of locality with linked lists, especially when the garbage collector is doing it for you, transparently. https://en.wikipedia.org/wiki/CDR_coding https://en.wikipedia.org/wiki/CDR_coding
lispm 11y ago
> But list efficiency and manipulation would likely be futile. Today, cache is king. Which means, linked lists are out. Out for what? > CAR/CDR? Let's not. Works okay even today on a typical Intel 64bit processor. > The glory days were not that glorious. There are stories out there of runaway garbage collections, that grinded on for days. Maybe in the early days. Lisp Machine development started in the mid 70s and ended in the early 90s. In the later days its GCs (it provided several different, cooperating GCs) were quite sophisticated. > Today you get garbage collections in your web browser that would embarrass any Lisp Machine ever built. It won't. Browser GCs are actually not more sophisticated compared to a later day Symbolics GC. The language model of JavaScript is much more primitive than what ran on a Lisp Machine. Lisp Machines had the same problem like we have today: a hierarchy of memory with different speeds. Very little 'fast' memory, and much much slower, but much larger, virtual memory. Actually the Symbolics Lisp Machines had pretty sophisticated GCs which you even won't find today on typical machines. Caching was all important on Lisp Machines and there was a lot done for that. A typical Lisp Machine in the Mid 80s had something like 16 MB RAM and 100 MB or more virtual memory on slow disks locally or over the network. End 80s it was 40MB RAM and a couple of hundred MB virtual memory on local disks. Without effective caching strategies this would not have been useful. Some special machines had more RAM, but this was very very expensive. These machines saved optimized images from which they booted. The memory was sorted according to object types into regions. Lists were converted into a vector-like representation (cdr coding), etc etc. At runtime a copying GC would move objects around into generations with object-sorted regions, improving locality. An ephemeral GC tracks changed memory in RAM. Additionally there were a lot of data structures which were under special memory management like networks packets or raster arrays.
- raphaelss 11y ago
  Is there any resource you recomend to someone that wants to understand the implementation of these systems? Not the implementation of lisp, but the implementation of these specific environments (lisp machines os's) in lisp. Specially with regards to memory management. EDIT: you seem to have posted a relevant link in another comment as I wrote this one, but I'd love more information if available.
lispmachina 11y ago
50 years of list processing, and member is still not O(1) :(

duncan_bayne 11y ago

Sure. I don't think anyone is arguing that we should fire up a Symbolics machine in 2015 and try to get work done on it. Rather, it's the spirit of the machines - inspectable and programmable from the ground up - that's worth preserving.

lectrick 11y ago
> inspectable and programmable from the ground up - that's worth preserving. This is what made me curious about the Smalltalk-based Squeak VM http://squeak.org/ http://squeak.org/. Its entire interface and stack was inspectable and manipulatable in real time. In practice it seemed a little buggy, though. If you installed Squeak programs too willy-nilly, pretty soon you'd get errors due to incompatibilities.

digi_owl 11y ago

And you can still have GC problem. Google ran into that with their Dalvik VM in Android.

kazinator 11y ago

> Which means, linked lists are out. CAR/CDR? Let's not. Data structures are dictated by the requirements of what you're doing, not the machine. Linked lists are out? The C middleware that runs everything is full of "struct foo { struct foo * next; int other_field ... }". Linked lists benefit from caching, like other kinds of data. > Today you get garbage collections in your web browser that would embarrass any Lisp Machine ever built. The garbage collection in your web browser is complete, utter garbage compared to what Lisp people were doing 30-40 years ago. Sorry! (I will add to this comment later; I have to go to Task Manager and kill the web browser.)

physguy1123 11y ago
> The garbage collection in your web browser is complete, utter garbage compared to what Lisp people were doing 30-40 years ago. Sorry! Can you back that statement up? GC has advanced heavily over the years (and still is).The first paper on generational GC was published in 1984, and I would imagine that it has drastically improved since then. I don't think that generational GC even landed in SBCL until sometime around 2005. Without anything to back that up, your post just sounds like Lisp fanboyism.
- gnaritas 11y ago
  Not the OP, but LISP machines had hardware incremental GC, I'd say GC in the hardware is pretty bad ass and was probably more predictable than modern software based GC.
- lispm 11y ago
  You could read the chapters on memory management and GC in the Symbolics Genera 8 manuals: areas, generations, resources, ephemeral GC, generational copying GC, full GC, ... http://bitsavers.informatik.uni-stuttgart.de/pdf/symbolics/software/genera_8/Internals.pdf http://bitsavers.informatik.uni-stuttgart.de/pdf/symbolics/s...
kristianp 11y ago
"The C middleware that runs everything is full of "struct foo { struct foo * next; int other_field ... }"." C datastructures most commonly used are Array of structs, Trees and Hashes. Linked lists are not commonly used I imagine. I don't have any stats to back that up though, neither did you.
- agumonkey 11y ago
  It's still interesting to see the duality in both paradigms. Lisp goes for genericity with the cons based list, while "static languages" reimplements them under encapsulated names. I'm not trying to compare per se, just to look at both side of the coin.

prestonbriggs 11y ago

Cdr-coding is a fine way to take advantage of locality with linked lists, especially when the garbage collector is doing it for you, transparently. https://en.wikipedia.org/wiki/CDR_coding https://en.wikipedia.org/wiki/CDR_coding

lispm 11y ago

> But list efficiency and manipulation would likely be futile. Today, cache is king. Which means, linked lists are out. Out for what? > CAR/CDR? Let's not. Works okay even today on a typical Intel 64bit processor. > The glory days were not that glorious. There are stories out there of runaway garbage collections, that grinded on for days. Maybe in the early days. Lisp Machine development started in the mid 70s and ended in the early 90s. In the later days its GCs (it provided several different, cooperating GCs) were quite sophisticated. > Today you get garbage collections in your web browser that would embarrass any Lisp Machine ever built. It won't. Browser GCs are actually not more sophisticated compared to a later day Symbolics GC. The language model of JavaScript is much more primitive than what ran on a Lisp Machine. Lisp Machines had the same problem like we have today: a hierarchy of memory with different speeds. Very little 'fast' memory, and much much slower, but much larger, virtual memory. Actually the Symbolics Lisp Machines had pretty sophisticated GCs which you even won't find today on typical machines. Caching was all important on Lisp Machines and there was a lot done for that. A typical Lisp Machine in the Mid 80s had something like 16 MB RAM and 100 MB or more virtual memory on slow disks locally or over the network. End 80s it was 40MB RAM and a couple of hundred MB virtual memory on local disks. Without effective caching strategies this would not have been useful. Some special machines had more RAM, but this was very very expensive. These machines saved optimized images from which they booted. The memory was sorted according to object types into regions. Lists were converted into a vector-like representation (cdr coding), etc etc. At runtime a copying GC would move objects around into generations with object-sorted regions, improving locality. An ephemeral GC tracks changed memory in RAM. Additionally there were a lot of data structures which were under special memory management like networks packets or raster arrays.

raphaelss 11y ago
Is there any resource you recomend to someone that wants to understand the implementation of these systems? Not the implementation of lisp, but the implementation of these specific environments (lisp machines os's) in lisp. Specially with regards to memory management. EDIT: you seem to have posted a relevant link in another comment as I wrote this one, but I'd love more information if available.

lispmachina 11y ago

50 years of list processing, and member is still not O(1) :(