Hacker News Reader

Comment by dmpk2k | Hacker News Reader

I haven't looked in a while, so I'm wondering what SBCL's GC latency profile is like nowadays. IIRC, it used to be a non-incremental STW conservative GC, which is a bit unfortunate.

View on HN

It's at least good enough to release a game on Steam. Here's an experience report: https://raw.githubusercontent.com/Shinmera/talks/master/els2... (https://kandria.com/)

> Overall we have needed to do surprisingly little actual performance analysis and optimisation work to make Kandria run well. This is definitely in large part thanks to SBCL’s quite good native code compiler and type inference systems, and the prior work we’ve done to design critical libraries to not be completely obscene in terms of their performance characteristics.

> […]

This might align with your interest, from 2023.

https://applied-langua.ge/~hayley/swcl-gc.pdf

Thank you!

Which is itself based on Immix which was really neat:

https://www.cs.cornell.edu/courses/cs6120/2019fa/blog/immix/

Cool!

Follow-up question: is there a way to "freeze" the GC? As in, I've done all my allocations, now I want to run a main loop uninterrupted, and force clean up inside at_exit().

Try setting or binding SB-KERNEL:*GC-INHIBIT* to true.

That's a recipe for disaster. Never do that.

Damn, I searched the sources on GitHub for WITHOUT-GC but found nothing; I should have searched for SB-SYS:WITHOUT-GCING which is the actual user-facing interface. Thanks for the correction.

SYS:WITHOUT-GCING is better but is still fraught with danger (that's why I didn't mention it).

I think you'll want without-interrupts for that: https://sbcl.org/sbcl-internals/The-deferral-mechanism.html

That's not related to garbage collection.

If you're not allocating, the gc won't run anyway. If you made a mistake and are allocating where you don't want to be, a gc pause might be preferable to a crash.

It's also generational and moving, but other than that you're right.

For anyone wondering how it can be conservative and moving, for values that may or may not be pointers, it treats the data as pinned.

Originally CMUCL targeted RISC processors that had a lot of registers, so it maintained two stacks. X86 is extremely register starved, so the conservative GC was written.

In practice, the conservative nature doesn't cause problems on 64 bit architectures.

Why would a lisp gc need to be conservative, anyways? Unless we're talking about ffi or something.

Untagged memory addresses or integers may be produced as intermediate results.

I've found it to be pretty performant, but I rarely push it so who knows. SBCL is often good at avoiding allocations if you type hint things, which I'm usually doing when I need performance (messing around with sims mostly). But of course if you're doing unavoidably allocation-heavy work that doesn't do anything for you, so I'm not sure how much the gc hurts

Reply on news.ycombinator.com