> Uncontended atomic operations are ~2-3x slower than their nonatomic analogs, which is still very fast. More like up to 20x slower; atomic reference counting

> Uncontended atomic operations are ~2-3x slower than their nonatomic analogs, which is still very fast. More like up to 20x slower; atomic reference counting has to hit the L3 cache at least. A quick benchmark seems to confirm that. Also, there are still some nasty corner cases with pointers that are shared between threads (because reading/writing a pointer and updating its associated reference count are not a single atomic operation). > Also I'd expect that GCs should experience a slowdown in the contention scenario, due to write barriers; is it so? Write barriers only come into play when pointers on the heap or in static memory are being modified. Reference counting means that you need to update the reference count whenever you assign references, even from one local variable to another (much of the work that Apple's done is to use compiler optimizations to get rid of those that are provably unnecessary). For example, having multiple threads traversing a tree in parallel can generate a lot of contention in the RC case, but none for a GC with a write barrier. Deferred reference counting is closer in performance to GC, but then you have to write most of the machinery of a tracing GC, too.