In this age of marketed Lisp-based architectures, this paper still presents one of very few accounts of powerful compilation techniques for Lisp on so-called "stock architectures," and I have received in the interim many requests for it.
Apple's MCL used the MMU for the stock Motorola 68020+ (M68020 + MMU, 68030/40 with included MMU, ...) processors for an efficient GC: the Ephemeral GC, using a table of changed memory pages, which was maintained by the MMU.
This idea was added by Apple to their first ARM CPUs, to get an efficient GC on tiny devices, running either a Lisp dialect or in the product, the Virtual Machine for NewtonScript.
But today's CPUs are very very different: an example is Apples M2 Ultra SOC. We don't have a Lisp implementation which has an even remote idea how to get "full" performance out of the combination of a larger number of Efficient+Performance cores, many GPU cores, Neural processing Unit + media engine + high-bandwidth unified memory. Most current more advanced Lisp engines make only use of a (not so large) count of multiple CPUs (only a few use multiple cores for the GC), some SIMD features, none (AFAIK) make use of the rest...
Lucid was founded in 1984, the same year work started on Coral Common Lisp, which became MCL. The Spice Lisp rewrite to run on stock hardware, leading to CMUCL, started in 1985.
I get the impression that using the MMU to record dirtied pages has fallen out of fashion, being less performant than manual card marking. I haven't kept close tabs on what SBCL is doing there, but there's been a lot of work on it.
I fully agree about modern computing needs diverging from what Lisp has been aimed at. In particular, array-oriented representations seem better than linked representations.
In this age of marketed Lisp-based architectures, this paper still presents one of very few accounts of powerful compilation techniques for Lisp on so-called "stock architectures," and I have received in the interim many requests for it.
Oh how times have changed!
I think Lucid was one of the drivers for really performant Lisp on stock hardware? And CMUCL.
There's room for even more improvement.
Apple's MCL used the MMU for the stock Motorola 68020+ (M68020 + MMU, 68030/40 with included MMU, ...) processors for an efficient GC: the Ephemeral GC, using a table of changed memory pages, which was maintained by the MMU.
This idea was added by Apple to their first ARM CPUs, to get an efficient GC on tiny devices, running either a Lisp dialect or in the product, the Virtual Machine for NewtonScript.
See for some info on the ARM610 and Garbage Collection: https://wiki.preterhuman.net/A_Call_to_ARM
But today's CPUs are very very different: an example is Apples M2 Ultra SOC. We don't have a Lisp implementation which has an even remote idea how to get "full" performance out of the combination of a larger number of Efficient+Performance cores, many GPU cores, Neural processing Unit + media engine + high-bandwidth unified memory. Most current more advanced Lisp engines make only use of a (not so large) count of multiple CPUs (only a few use multiple cores for the GC), some SIMD features, none (AFAIK) make use of the rest...
Lucid was founded in 1984, the same year work started on Coral Common Lisp, which became MCL. The Spice Lisp rewrite to run on stock hardware, leading to CMUCL, started in 1985.
I get the impression that using the MMU to record dirtied pages has fallen out of fashion, being less performant than manual card marking. I haven't kept close tabs on what SBCL is doing there, but there's been a lot of work on it.
I fully agree about modern computing needs diverging from what Lisp has been aimed at. In particular, array-oriented representations seem better than linked representations.