21–30 of 32 posts
Earlier quoted context omitted.
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().
I think you'll want without-interrupts for that: https://sbcl.org/sbcl-internals/The-deferral-mechanism.html
Earlier quoted context omitted.
Try setting or binding SB-KERNEL:*GC-INHIBIT* to true.
That's a recipe for disaster. Never do that.
For those who didn't follow, some news from 2022: - SBCL is now callable as a shared library - SIMD support - faster (de)compression with zstd - TRACE supports tracing macro functions, compiler-macro functions, individual methods and local functions (flet and labels) - the SBCL repository reached 20,000 commits. - Prebuilt SBCL binary for Android (Termux) (unofficial) https://lisp-journey.gitlab.io/blog/these-years-i…
SIMD support is huge, and if you're willing to do a little hacking (SBCL is very easy to extend) you can even use it without the intrinsics
Earlier quoted context omitted.
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.
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.
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 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.
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 c…
Earlier quoted context omitted.
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 c…
Why would a lisp gc need to be conservative, anyways? Unless we're talking about ffi or something.
Earlier quoted context omitted.
SIMD support is huge, and if you're willing to do a little hacking (SBCL is very easy to extend) you can even use it without the intrinsics
In fairness, "SIMD support" is not exactly "the compiler can reduce code to AVX instructions" but more like "you can now write non-portable custom assembly-like code to make your code faster".
Earlier quoted context omitted.
Wasn't ITA Software using CCL before their acquisition by Google? I wonder why they switched to SBCL. Right now CCL seems to be rather understaffed but this wasn't the case when they switched, as far as I know.
Back in 2009, before the acquisition, a developer ITA software presented at the SBCL workshop (audio here: http://www.sbcl.org/sbcl10/materials/cracauer-talk.ogg ), talking about the company's use of SBCL. They'd also talked about using CCL; the last I heard was that they used one on desktops, the other in prod deployments.
Earlier quoted context omitted.
SIMD support is huge, and if you're willing to do a little hacking (SBCL is very easy to extend) you can even use it without the intrinsics
In fairness, "SIMD support" is not exactly "the compiler can reduce code to AVX instructions" but more like "you can now write non-portable custom assembly-like code to make your code faster".