3 ms·

"Those who don't know Lisp Machines are doomed to reinvent them, poorly."

• tachyonbeam 7y ago
  Why don't you provide some comments on how Lisp machines implemented GC acceleration, and how the approach outlined in this paper is worse? Go...
• monocasa 7y ago
  Eh, this is pretty different than Lisp Machines of old. Most of the minicomputers they we're competing with were more or less true von Neumann architectures without caches. That meant that one those systems the I fetch of the interpreter itself was constantly competing for memory bandwidth with the actual Lisp code it's interpreting and it's data. By pushing the interpreter into microcode, you've created a Harvard arch where the interpreter can fetch out of uCode entirely and not pollute the main system bus. IMO this is why Lisp machines dies off coinciding with the usage of caches (particularly I caches) in those kinds of computers. At that point the hot path of the interpreter can totally live in I cache, so it's not polluting system bandwidth the same way anymore, and now the biggest reason in favor of a dedicated lisp machine is moot. This work in the article is actually really cool and goes way beyond any lisp machines by off loading GC to another independent unit that runs in parallel to the main CPU, interleaving into the regular system memory bandwidth in a clean way.