Hello,

I’m working on a game in Rust but interested in trying out (SB)CL. That being said I’m worried about GC pauses for the type of game I’m making and would like to create a relatively simple benchmark to gauge the level of inconvenience this would cause me. I’d like to do this upfront since I already have a decent bit of progress on the Rust side. Originally the game was being developed in Godot but it ended up being a little too CPU heavy for GDScript (not GC related as far as I could tell, but they have reference counting over there). Then I migrated to Rust and performance-wise everything is working great, but I’ve been wanting to try CL for a while now and I can afford a couple of weeks of distraction…

How can I benchmark the GC? I know something I can try is simply calling it at the end of every frame and measuring the time there, but I’m curious about how to time it in its default settings.

I also saw: https://groups.google.com/g/sbcl-devel/c/VAA4SkQo3jM But as someone unfamiliar with SBCL development, is this GC something that we can expect to see within a year or two? I’m eager to try it, seeing as the author of that post stated:

The longest a thread should ever be “paused” (not doing its own work) is about 100 microseconds. “paused” actually means doing work for the GC.

Which sounds fantastic, not even 1ms at its highest.

  • DecwebBEnglish
    1·
    1 year ago

    SBCL has gc hooks you might also use too, though I don’t think it’ll give you the duration of the just-finished gc.

    Variable: *after-gc-hooks* [sb-ext]

    You might be able to just increment a counter, and call (room) each time, and at least log the data (assocaited with the counter) for subsequent analysis.

  • DecwebBEnglish
    1·
    1 year ago

    You might read docs about some CL based games, like Khandria, where they talk about dealing with gc. (TL;DR, not a major problem). Sorry, I don’t have a link for you.

    Note that you can also work to writing less consing-intensive code too (more preallocated data structures, efficient use of fixnums, the stack, and lisp-specific extensions that allow you to do more tricks with the stack or malloc()'d memory.