Hacker News Reader

Comment by vladharbuz | Hacker News Reader

I think Lisp is wonderful, and I would love to develop games using Lisp. However, I was under the impression that, by all accounts, developing games in Lisp is completely unrealistic due to the garbage collector.

I'm not familiar with Common Lisp, but in Racket, “GC pauses [...] typically run from 50ms to 100ms” [0]. On a 16ms maximum frame budget, that doesn't really work. Am I missing something?

[0]: https://docs.racket-lang.org/portaudio/index.html#%28part._....

EDIT: I'm aware of GOAL at Naughty Dog — Andy Gavin who wrote it described the GC as being a problem in a HN comment. [1]

[1]: https://news.ycombinator.com/item?id=1998321

View on HN

You can write Lisp in a way that you manage your own allocations, including avoiding the heap. It defeats part of the point of Lisp, but sometimes you can use that coding style for a subset of your program that shouldn’t be leaning on the GC too much.

I don’t do game development, but in scientific computing, I rely on the GC a lot for workload preparation and other administrivia, then adopt a GC-famished Lisp style for the hardcore numerical computing part.

To be sure though, GC-less Lisp programming takes a great deal of effort and knowledge. It’s not exactly an a la carte option. But the fact it’s possible means latency-sensitive applications are possible. Fortunately, Lisp’s primary benefit isn’t the GC.

And with DISASSEMBLE[1] you can easily check to be 100% sure.

[1] http://clhs.lisp.se/Body/f_disass.htm

Anyone know if there have been attempts at concurrent garbage collection in any of the major lisp implementations (whether CL or Scheme). Maybe Clojure?

Clojure uses the underlying host's GC (e.g., JVM, CLR or JS engine). It also typically generates rather more garbage than other languages may due to immutability by default. As with all things, you can avoid the garbage if you are willing to abandon the usual idioms.

I heard Allegro's GC is concurrent and that "a new GC seems to be brewing in SBCL".

Also Clasp's GC (via Boehm GC and MPS).

Last but not least, quoting: "when one runs ABCL on a suitable JVM with ZGC or Shenandoah, then it has parallel GC".

https://twitter.com/stylewarning/status/1387809546287022082?...

https://lisp-journey.gitlab.io/blog/pro-mailing-list-on-comm...

Naughty Dog historically disagreed with this [0], plenty of games these days are developed in languages with GC but it is a performance trade off. For maximum performance any Lisp is probably not the way to go but I don't think it's unfeasable.

I want to say in general e.g. SBCL (a popular common lisp implementation) will perform a lot better than Racket. Racket is a great language but performance is not it's strong suit.

[0]: https://en.m.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

Currently, but hopefully no longer in the near future, SBCL’s garbage collector is extremely meh. It’s hard to tune, it stops the world, etc.

Otherwise SBCL is a wonderful implementation.

Is there some recent work going on in SBCL on its GC?

yes!

> A new garbage collector seems to be brewing in SBCL git...

https://twitter.com/stylewarning/status/1387809546287022082?...

I used Clozure CL (and I'm now a LispWorks customer) for this reason.

There’s a lisp-like language without a GC called Carp [1]. I believe the goal was enabling real time applications and specifically games. I’ve only toyed with it a tiny bit, but it has an ownership memory model inspired by Rust. Pretty neat project!

[1] https://github.com/carp-lang/Carp

The `portaudio` is a few years old, so I have a hunch that the comment refers to the old backend "Racket BC". The new backend "Racket CS" has a new garbage collection mode "incremental", which I understand is better for this usage scenario. I don't have any numbers though.

I got some more information from Flatt.

The new incremental mode means the 16ms deadline is within reach. In fact if the screen is not involved, then 1-2ms is reachable.

On macOS a screen-refresh can cause a 16ms pause.

Didn't incremental GC exist before CS work even began? I certainly remember seeing it although it was not default. Or is this a different implementation?

Yes, incremental GC exists in both the CS and BC variants. It works quite differently in each one, though, because the general GC architecture in each is different.

Kandria is written in Common Lisp and manages to deal with this.

https://kandria.com/

I can't speak to the exact numbers, but in comparison to Scheme based lisps, CL has a much wider variety of optional hints you can give to the run time to drastically speed up performance thanks to its more pragmatic industrial heritage.

This is correct. You can declare the types of objects (DECLARE TYPE) which has repercussions on size and allocation, you can declare the type of optimizations you want to do (DECLARE OPTIMIZE) be them speed space or safety, and you can declare things to be stack allocated (DECLARE DYNAMIC-EXTENT), avoiding GC of a particular object altogether.

This is what makes CL feel so good to use. I can declare optimizations and types and verify it with DISASSEMBLE to see the resulting assembly. (If your CL implementation compiles to assembly, such as SBCL) It's possible to make things go really fast this way, too.

It's worth mentioning that in general, racket is just a lot slower than SBCL. I would never write performance critical software in racket

Andy derides the GC of a particular common lisp implementation (Allegro) and praises the GC of an implementation of a language with broadly similar semantics and data model (Ruby). The conclusion to take from that is that one CL implementation had a crappy GC, not that CL is not amenable to fast garbage collection.

Reply on news.ycombinator.com