5 ms·

The frustrating thing is that people say this without realizing that GCs haven't, and by necessity cannot provide the type of deterministic and predictable perf

by _se 3y ago

The frustrating thing is that people say this without realizing that GCs haven't, and by necessity cannot provide the type of deterministic and predictable performance that would lead someone to use Rust/C++ and friends. There are few people using Rust who don't have experience in other languages. It's wild that you think you know about their use cases better than they do. Your comment says "I have never worked on a problem where GCs are problematic". That is great for you, but it has little to do with the value of improving the situation for native, no runtime, performant languages.

pjmlp 3y ago
Only for those that put the word GC on the same bag, without understanding there are tons of approaches, and many languages with automatic resource management also provide deterministic features.
hgs3 3y ago
You can make garbage collection deterministic. Tracing collectors can be designed to accept a timeout so you can "collect" during downtime and resume execution on a predictable schedule. And with reference counting the cost of RC bookkeeping is smeared predictable across the run of the program. The real problem is many GC implementations lack customization and you're stuck with whatever GC algorithm the language implementers pick.
- alexchamberlain 3y ago
  You can do RC memory management without the overhead of a GC runtime though.
  - jayd16 3y ago
    As described (ie. only run when I say so), the GC is less overhead than ref counting because you're not even paying for the cost to free things.
- murderfs 3y ago
  > And with reference counting the cost of RC bookkeeping is smeared predictable across the run of the program. The biggest downside of naive reference counting usually isn't the cost of reference counting itself, it's being left stuck holding the bag when you're unlucky enough to be the last deref on a giant object graph. You can move the destruction onto a separate finalizer thread like what most runtimes that use tracing GCs do, but then you end up running into CPU scheduling issues if you're not overprovisioned.
- pizlonator 3y ago
  There’s much more to it than you say. The real problem is most GCs are built with a “throughput first” mindset and determinism is bolted on. The details of how to build a deterministic GC are beyond the scope of a HN post lol
IncreasePosts 3y ago
I realize this is a biased sample, but about 99% of rust projects I see on hn or lobsters wouldn't have been encumbered by a GC
tombert 3y ago
Most people aren't writing a kernel. I've seen plenty of Rust projects writing things like web servers, where a low-latency GC (like Go's) would work just fine. Obviously there's a lot of problems where a GC would be a real performance issue, but I think that people will reach to "rewrite in Rust" too quickly sometimes. Manual memory management is hard, and most software engineers, sort of by definition, are "average".
- forty 3y ago
  One important thing is that Rust is an expressive language that's pleasant to use, unlike Go :) that would explain why many side projects that could be in Go are actually in Rust even if they could have been done efficiently in Go too.
  - tombert 3y ago
    Fair! I actually kind of like Go but it's not a language I reach for very often. Still, the point I was making is that it's possible to have garbage collectors that get very low pause times (sub millisecond in Go's case [1]). It might still be an issue for a kernel or microcontroller, I'm not suggesting we always use a GC for every project, I don't think most people would, but I am suggesting that there are a lot of projects (most projects?) that would be better off using a low-latency GC instead of trying to handle memory directly. Even the JVM is getting better about this; there's already experimental support for a low-latency GC in some distributions of OpenJDK [2], which reportedly gets sub-millisecond pauses as well. If you have JVM support then you have access to good languages like Clojure. Personally, I actually think I'm reasonably-ok with manually managing memory, I've cut my teeth on enough C to write code that doesn't generally crash, but I still reach for a garbage collector whenever possible. Just because I think I'm capable of doing manual memory management doesn't mean that I think it's worth it for most things; nearly everything I do touches a network at some point, which means that avoiding latency is not really possible a lot of the time. [1] https://groups.google.com/g/golang-dev/c/Ab1sFeoZg_8 https://groups.google.com/g/golang-dev/c/Ab1sFeoZg_8 [2] https://wiki.openjdk.org/display/shenandoah/Main https://wiki.openjdk.org/display/shenandoah/Main
pizlonator 3y ago
I am saying that GCs can do it as a GC engineer

by _se 3y ago

pjmlp 3y ago

Only for those that put the word GC on the same bag, without understanding there are tons of approaches, and many languages with automatic resource management also provide deterministic features.

hgs3 3y ago

You can make garbage collection deterministic. Tracing collectors can be designed to accept a timeout so you can "collect" during downtime and resume execution on a predictable schedule. And with reference counting the cost of RC bookkeeping is smeared predictable across the run of the program. The real problem is many GC implementations lack customization and you're stuck with whatever GC algorithm the language implementers pick.

alexchamberlain 3y ago
You can do RC memory management without the overhead of a GC runtime though.
- jayd16 3y ago
  As described (ie. only run when I say so), the GC is less overhead than ref counting because you're not even paying for the cost to free things.
murderfs 3y ago
> And with reference counting the cost of RC bookkeeping is smeared predictable across the run of the program. The biggest downside of naive reference counting usually isn't the cost of reference counting itself, it's being left stuck holding the bag when you're unlucky enough to be the last deref on a giant object graph. You can move the destruction onto a separate finalizer thread like what most runtimes that use tracing GCs do, but then you end up running into CPU scheduling issues if you're not overprovisioned.
pizlonator 3y ago
There’s much more to it than you say. The real problem is most GCs are built with a “throughput first” mindset and determinism is bolted on. The details of how to build a deterministic GC are beyond the scope of a HN post lol

IncreasePosts 3y ago

I realize this is a biased sample, but about 99% of rust projects I see on hn or lobsters wouldn't have been encumbered by a GC

tombert 3y ago

Most people aren't writing a kernel. I've seen plenty of Rust projects writing things like web servers, where a low-latency GC (like Go's) would work just fine. Obviously there's a lot of problems where a GC would be a real performance issue, but I think that people will reach to "rewrite in Rust" too quickly sometimes. Manual memory management is hard, and most software engineers, sort of by definition, are "average".

forty 3y ago
One important thing is that Rust is an expressive language that's pleasant to use, unlike Go :) that would explain why many side projects that could be in Go are actually in Rust even if they could have been done efficiently in Go too.
- tombert 3y ago
  Fair! I actually kind of like Go but it's not a language I reach for very often. Still, the point I was making is that it's possible to have garbage collectors that get very low pause times (sub millisecond in Go's case [1]). It might still be an issue for a kernel or microcontroller, I'm not suggesting we always use a GC for every project, I don't think most people would, but I am suggesting that there are a lot of projects (most projects?) that would be better off using a low-latency GC instead of trying to handle memory directly. Even the JVM is getting better about this; there's already experimental support for a low-latency GC in some distributions of OpenJDK [2], which reportedly gets sub-millisecond pauses as well. If you have JVM support then you have access to good languages like Clojure. Personally, I actually think I'm reasonably-ok with manually managing memory, I've cut my teeth on enough C to write code that doesn't generally crash, but I still reach for a garbage collector whenever possible. Just because I think I'm capable of doing manual memory management doesn't mean that I think it's worth it for most things; nearly everything I do touches a network at some point, which means that avoiding latency is not really possible a lot of the time. [1] https://groups.google.com/g/golang-dev/c/Ab1sFeoZg_8 https://groups.google.com/g/golang-dev/c/Ab1sFeoZg_8 [2] https://wiki.openjdk.org/display/shenandoah/Main https://wiki.openjdk.org/display/shenandoah/Main

pizlonator 3y ago

I am saying that GCs can do it as a GC engineer