3 ms·
I have been using the Boehm-Demers-Weiser GC for jank [1], the native Clojure dialect on LLVM with C++ interop. Since jank is a Clojure dialect, and Clojure is
by Jeaye 3y ago
I have been using the Boehm-Demers-Weiser GC for jank [1], the native Clojure dialect on LLVM with C++ interop. Since jank is a Clojure dialect, and Clojure is built primarily on persistent, immutable data structures, there are potentially a lot of references to objects, potentially cyclical, across many threads, and there's a lot of garbage being churned. I originally started with reference counting and RAII, using boost::intrusive_ptr and an atomic count. The GC was actually 2x faster, in the sequence benchmark I was trying to optimize.
At this point, jank is generally several times faster than the equivalent Clojure JVM code. I'm sure there are better GCs out there, in terms of performance, and I have my eye on MMTK [2] for a future upgrade, but the fact that remains is this: the Boehm GC is stupid simple to integrate and it's surprisingly fast. Compare it to MPS, MMTK, and others and both the documentation and the actual dev work required are worlds apart.
For a project which needs a GC but doesn't need to pick the absolute fastest one first, it seems like the best option, based on my research and my experience.
1: https://jank-lang.org/ https://jank-lang.org/
2: https://www.mmtk.io/code https://www.mmtk.io/code
- pharmakom 3y agoImmutable structures cannot be cyclical. Maybe I’m missing something?
- nlitened 3y agoIn Clojure, the data structures may usually contain references to mutable cells, which in turn may form cycles.
- Jeaye 3y agoExactly as nlitened mentioned, Clojure has a few difference reference types, which are boxes that hold pointers to more immutable values. The values within those boxes can be changed transactionally. This allows for cyclical references.
- mtlmtlmtlmtl 3y agoJust want to say, Never heard of Jank before and it looks awesome, great work!. As more of a CL guy who's dabbled in Clojure but found it a bit too slow(but conversely I also miss the Clojure's data structures and transactional state in CL; multithread programming really isn't CLs strong suit, for obvious historical reasons), this might reinvigorate me. I may sit down one day soon and churn out some AOC or something in Jank just to get a feel. Cheers :)
- Jeaye 3y agoThe shameless plugging pays off! One more HN reader converted. :D Check it out, join our Slack, and stay tuned. jank's still under heavy development right now, and not ready for AOC this year, but it's getting close. The blog is the best way to watch the progress: https://jank-lang.org/blog/ https://jank-lang.org/blog/ Thanks for taking the time to comment!
- mtlmtlmtlmtl 3y agoWell, in that case, if you have any issues that are somehow well suited for a reasonably experienced C/Lisp programmer with almost no C++ experience(unless shaking my head over the code in the Arduino stdlib counts...), then maybe I'll sit down with one of those!
- Jeaye 3y agoThere will be a lot of room for this, once I build out more of the features. In particular, there will be a lot of Clojure libraries which need to gain jank support. Clojure doesn't require "porting", so to speak, since it has a special .cljc file which can use reader conditionals to check the host that it's in (clj, cljs, cljr, jank, etc). So anywhere those libs are using Java interop, we'd need to wrap it to use native interop instead. On the compiler and tooling itself, I have some open issues here: https://github.com/jank-lang/jank/issues https://github.com/jank-lang/jank/issues The vast majority of it is heavy C++ work, though. Outside of that, the biggest gains will come from time spent on packaging, distribution, and testing on various platforms. And if none of that sounds interesting or applicable, don't worry. Just be sure to join the Slack channel and hang out with us. :)