3 ms·
> But with with Swift, Rust and modern C++ the argument can be made that GC doesn't bring anything to the table. Well, it would be a bad argument :D A referen
by kaba0 4y ago
> But with with Swift, Rust and modern C++ the argument can be made that GC doesn't bring anything to the table.
Well, it would be a bad argument :D
A reference counter is arguably the slowest option, so Swift is out of the picture (besides it leaks circular dependencies). Rust is a good idea, but it is a tradeoff. Quite a lot of programs can’t be expressed with strictly tree-like lifecycles, and then you are either left with the yet again slower (A)RC, or unsafe. C++ is in pretty similar shoes. They are good for the niche they were made, systems/low-level programming.
Let me quote from the Garbage collector handbook: “above all, memory management is a software engineering issue. Well-designed programs are built from components [..] that are highly cohesive and loosely coupled. [..] modules should not have to know the rules of the memory management game played by other modules. [..] GC uncouples the problem of memory management from interfaces.”
It says nothing about not thinking about memory, you are free to optimize it where you need it.
EDIT: Oh and dynamic allocation is much faster with a modern GC than with malloc and friends, plus a moving GC can defragment heap.
- zozbot234 4y ago> A reference counter is arguably the slowest option, so Swift is out of the picture 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.
- kaba0 4y agoWell, 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.
- saagarjha 4y agoYou can do reference counting without making it atomic, by prohibiting sharing across threads. It’s not fundamentally required. See Rust’s Rc, for example.
- deleted 4y ago[deleted]
- germandiago 4y agoor boost local shared ptr