4 ms·

> ... plus [reference counting] interacts badly with how modern CPUs work. Can you expand on this?

• sweetjuly 2y ago
  I'm not sure what the reference to "modern CPUs" is, but a common complaint is that most reasonable reference counting implementations suffer very badly under contention. Specifically, if an object's reference count is contended (an object is being accessed/its pointer copied by many threads), it's possible that incrementing and then decrementing the reference count can take several hundred cycles due to either cache lines ping-ponging between cores or relatively expensive remote atomics (some Arm CPUs, I believe, allow the memory system to execute atomic operations in caches themselves to try and cope with contention/avoid moving cache lines back and forth by simply leaving them in a shared cache). In reality, your milage will heavily vary. If you don't have contention (you don't commonly share objects across multiple threads concurrently), it's likely that reference counting will perform very well. Whether this is the common case really depends on the kinds of software you write.
  • magicalhippo 2y ago
    Same object doesn't have to be contended if the reference count is sharing cache line with another reference count. I've seen this happen in cases arrays of objects are allocated, ie one per thread, and then handed to a thread pool to work on. Even if heap allocated, if the object is just a reference counter and a few pointers, the memory allocator can fit several of them next to each other causing them to share cache lines, which causes the performance issues with atomic operations. Depends on implementation of things of course, but can be a pitfall.