3 ms·

Four reasons: 1. Reference counting scales with number of dead objects while Mark+Sweep typically scales with number of alive objects. This means that if you c

Four reasons: 1. Reference counting scales with number of dead objects while Mark+Sweep typically scales with number of alive objects. This means that if you collect infrequently enough, a GC will have strictly less work to do. 2. RC involves a write whenever the reference count is increased. This means that in multi threaded contexts you need an atomic whenever a new reference is added. This will absolutely destroy performance in multi-threaded apps (this is the main reason why multi-threading in python doesn't exist). 3. RC requires a fairly high amount of metadata (often 32-64 bits per object). Mark sweep on the other hand often only needs a few (e.g. 2) bits per object. This is pretty heavy, especially for languages where everything is an object. 4. Circular references That said there is recent research suggesting that good algorithms can be made by combining RC with mark-sweep (e.g. https://dl.acm.org/doi/10.1145/3519939.3523440 https://dl.acm.org/doi/10.1145/3519939.3523440)

ithkuil 4y ago
The sweep phase scales with the number of dead objects. Copying collectors have the property of scaling with the number of surviving objects, which makes them suitable for the first generation (nursery).
ratorx 4y ago
Do you have any links to Python Atomic RC? I don’t know much about it, but I’d heard that it was the global interpreter lock that prevented multi-threading. I’d be surprised if the overhead of Atomic RC was that much, since it is a common pattern in Rust.
- adgjlsfhk1 4y ago
  python doesn't have atomic rc. the gil prevents multithreading because experiments into removing the gil and replacing it with atomic reference counting had too high a performance overhead (roughly 2x for single threaded code). this is less of a problem for rust for 2 reasons: ARC is opt in and it's only used for a small fraction of objects, and compilers can do some fancy tricks and delete pairs of increments and decrements if it can prove that they don't cause corruption.

ithkuil 4y ago

The sweep phase scales with the number of dead objects. Copying collectors have the property of scaling with the number of surviving objects, which makes them suitable for the first generation (nursery).

ratorx 4y ago

Do you have any links to Python Atomic RC? I don’t know much about it, but I’d heard that it was the global interpreter lock that prevented multi-threading. I’d be surprised if the overhead of Atomic RC was that much, since it is a common pattern in Rust.

adgjlsfhk1 4y ago
python doesn't have atomic rc. the gil prevents multithreading because experiments into removing the gil and replacing it with atomic reference counting had too high a performance overhead (roughly 2x for single threaded code). this is less of a problem for rust for 2 reasons: ARC is opt in and it's only used for a small fraction of objects, and compilers can do some fancy tricks and delete pairs of increments and decrements if it can prove that they don't cause corruption.