5 ms·

I'm not the OP, but: Whenever you update a reference count atomically, you need to use a memory barrier to ensure that that memory write becomes visible to the

I'm not the OP, but: Whenever you update a reference count atomically, you need to use a memory barrier to ensure that that memory write becomes visible to the other cores before any other memory operations you want to make. Those are not cheap, and doing one on every Py_IncRef and Py_DecRef will have performance implications somewhere between murderous and tragic.

wingo 17y ago
This is what I meant, yes. Note that you incur the cost on immutable data structures as well as mutable ones. You really trash your caches this way.
- haberman 17y ago
  You only pay a cost in cache if there is contention over a cache line. If there is no cache-line contention, I do not believe there is any overhead to atomic increment. See: http://software.intel.com/en-us/forums/intel-threading-building-blocks/topic/59268/reply/59046/ http://software.intel.com/en-us/forums/intel-threading-build...
  - haberman 17y ago
    And yet empirically there is a 20-40% slowdown: http://mail.python.org/pipermail/python-ideas/2009-November/006599.html http://mail.python.org/pipermail/python-ideas/2009-November/... The message is not too specific; is this on an SMP machine? Are these multi-threaded tests? Given the previous message I cited, I would expect the single-CPU, single-threaded case to be unaffected by making incref and decref atomic.
haberman 17y ago
I don't think atomic refcounting requires memory barriers. You only need to delete the object when the refcount drops to zero. There is no other memory that needs to be viewed consistently with respect to the refcount.