Hacker News new | ask | show | jobs
by 3836293648 610 days ago
Because if you can afford GC you're not using C/++. We need memory safe systems stuff. Higher level memory safety has been solved for decades
1 comments

I don’t buy that at all.

If I could use C++ with GC, I would - but I can’t because other than Fil-C++ no GC works soundly with the full C++ language, and those that work at all tend to be unreasonably slow and flaky due to conservatism-in-the-heap (Boehm, I’m looking at you). Reason: GC and memory safety are tightly coupled. GC makes memory safety easy, but GC also requires memory safety to be sound and performant.

So there isn’t anything else out there quite like Fil-C++. Only Fil-C++ gives you accurate high perf GC and the full C++ language.

Finally, “affording” GC isn’t really a thing. GC performs well when compared head to head against malloc. It’s a time-memory trade off (GC tends to use more memory but also tends to be faster). If you want to convince yourself, just try a simple test where you allocate objects in a loop. Even JS beats C++ at that benchmark, because GCs support higher allocation rates (just make sure to make both the C++ and the JS version complex enough to not trigger either compiler’s escape analysis, since then you’re not measuring the allocator).

"affording" GC is absolutely a thing. You're measuring the wrong thing. It's primarily about latency, not throughput, and GC can only go head-to-head on throughput.

Secondly you have places where you don't have dynamic memory at all which you're also conveniently ignoring.

Fil-C has a concurrent GC. It doesn’t stop your program, ever.

If your C code doesn’t dynamically allocate then it won’t create any GC load in Fil-C.

> Fil-C has a concurrent GC. It doesn’t stop your program, ever.

what about performance/throughput compared to when you allocate stuff on stack?