| 20 Mar 2026 |
 emily | rolling your own structures is probably preferable to the allocator API unless you truly can't get away with it sadly | 12:19:08 |
| emily | right. but if binding to Boehm / letting C++ handle allocations and finalization is the short term plan I wouldn't think it'd make sense to move to something slower when it doesn't help gradually transition the Rust code to what will be required for rooting objects later anyway | 12:20:32 |
 piegames | indeed | 12:21:48 |
| piegames | though it shall be noted that a) the current plan hinges on cxx working out (or some other form of ergonomic Rust C++ interop), and b) will come at an unknown performance cost due to FFI linking | 12:23:10 |
| piegames | * though it shall be noted that the current a) plan hinges on cxx working out (or some other form of ergonomic Rust C++ interop), and b) will come at an unknown performance cost due to FFI linking | 12:23:21 |
 Sergei Zimmerman (xokdvium) | I mean, it’s also possible to manually root with Boehm. There are callbacks for that - just a question of manually tracking roots on the rust side and throwing that over the fence into a Boehm callback | 12:23:46 |
| Sergei Zimmerman (xokdvium) | That’s how crystal does it with coroutines | 12:23:57 |
| emily | there's no need for that I don't think | 12:24:08 |
| emily | the Rust frames will look just like C++ ones as far as Boehm is concerned | 12:24:21 |
| Sergei Zimmerman (xokdvium) | I mean if it just lives on the stack/registers/TLS it would just work, yes. | 12:24:43 |
| piegames | Though still, manual rooting would be a "solution" for the rooting problem in Rust GC. Admittedly an unsafe one, but still an improvement over anything C++ | 12:25:34 |
| emily | (that said the perf tradeoffs between sufficiently good refcounting and sufficiently good GC aren't necessarily obvious, though Nix has little use for latency over throughput and lacks complex finalizers so likely to tilt in the GC direction. OTOH memory usage is famously bad so eager collection might not be the worst thing...) | 12:25:49 |
| emily | what do you mean by perf cost due to FFI linking? | 12:26:17 |
| emily | manual rooting without an API that enforces it is vastly less safe than Boehm in C++ tbh | 12:26:59 |
| emily | wouldn't recommend that under any circumstances. would be better to just punt on rooting by trampolining and only collecting when there are no active Rust frames than that (IIRC one of the major GC crates works this way, I forget which one) | 12:28:31 |
| piegames | mostly lack of inlining, AFAICT, possibly also some ABI shenanigans w.r.t. which values have to go on the stack | 12:30:47 |
| piegames | as in, linking objects written in two different languages presents an optimization boundary which prevents LTO | 12:31:19 |
| emily | cross-language LTO will get you inlining | 12:31:22 |
| Sergei Zimmerman (xokdvium) | Can’t you compile the C++ part to llvm it with C ABI and link that with the rust shim? | 12:33:07 |
| emily | (and it's unlikely you can even measure ABi differences esp. since the less optimal case you is just what C++ uses for all code) | 12:33:18 |
| emily | cxx binds directly to the Rust | 12:33:32 |
| Sergei Zimmerman (xokdvium) | In reply to @xokdvium:matrix.org
Can’t you compile the C++ part to llvm it with C ABI and link that with the rust shim? (That’s also compiled down to llvm-ir) | 12:33:32 |
| emily | but yes you can LTO between the two languages | 12:33:40 |
| emily | the Rust toolchain has specific support for it | 12:34:00 |
| Sergei Zimmerman (xokdvium) | Well fat lto is basically just linking llvm ir modules together, right? | 12:34:06 |
| emily | yeah | 12:34:13 |
| emily | but you can do cross language thinlto too | 12:34:21 |
| emily | https://doc.rust-lang.org/rustc/linker-plugin-lto.html | 12:35:14 |
| emily | (for clarity: cxx is a Rust crate. it just layers on top of native C FFI in Rust to bind to C++) | 12:37:56 |
| emily | (incl interop with C++ smart pointers etc.) | 12:38:14 |
