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.
> 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.
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().
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.
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.
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.
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
> 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.
> […]