Re:Why is D's garbage collection slower than GO's?
by kaba0 on Saturday October 29, 2022 @07:41AM
(#33383155)
Well, ever seen a C++ program that seemingly finished execution, but still haven’t exited?
That’s shared pointers recursively freeing up their reference trees. There is a great paper showing that RC tracks object death, while tracing GCs track object “liveness”, so its essentially two sides of the same coin.
As for RC, sure, at compile time many of the work can be omitted, but atomic writes needed for the counters are fundamentally slow operations on modern architectures.
Re:Why is D's garbage collection slower than GO's?
by saagarjha on Saturday October 29, 2022 @08:24AM
(#33383453)
You can do reference counting without making it atomic, by prohibiting sharing across threads. It’s not fundamentally required. See Rust’s Rc, for example.
Re:Why is D's garbage collection slower than GO's?
by germandiago on Sunday October 30, 2022 @02:44PM
(#33397321)
or boost local shared ptr
It's not that simple. Obligate refcounting has lower throughput than obligate tracing GC but offsets that with more predictable latency, which might be good for the Swift use case. Rust uses a mix of stack-based allocation, manual heap allocation and RC - and the RC only needs to manage "owners" as determined via the borrowck, as opposed to ephemeral references. So is way more efficient than something like Swift ARC, where refcounting is essentially ubiquitous and any operations via references will incur slow atomic RC updates.