4 ms·
Reference counting is nothing new. Visual Basic used it before the transition to .NET. Python uses it, if I remember correctly (with occasional GC to avoid leak
by pmjordan 15y ago
Reference counting is nothing new. Visual Basic used it before the transition to .NET. Python uses it, if I remember correctly (with occasional GC to avoid leaks due to cycles). There are probably countless other examples.
Reference counting is also not even that great for shared memory multithreading. The (atomic) increment/decrement operations typically cause lots of cache invalidation, so you'll get a slowdown even for immutable objects.
- angersock 15y agoRef counting by itself is nothing new, agreed. The fact that I can reliably say when things go out of scope in C++, though, combined with ref counting, is quite handy. Interesting point about the cache invalidation, though. I wonder if we'll see chip vendors going out of their way to improve performance and invalidation when using atomic ops.
- pmjordan 15y agoI wonder if we'll see chip vendors going out of their way to improve performance and invalidation when using atomic ops. They already put a lot of effort into making this stuff as efficient as possible - the fact that Intel is going in the direction of hardware transactional memory indicates to me that they don't think the bus locking/cache snooping approach scales, and I can't say I'm surprised.
- ootachi 15y agoYeah, atomic RC hurts a lot (5x-10x slower, based on the measurements I've seen -- Hans Boehm of Boehm GC fame did a presentation on this that you can find if you're interested). (This is a problem with Objective-C reference counting -- they use atomic ops for all reference counting I believe.) There's some work on mitigating its cost with per-thread reference counts arranged in a tree or whatever, but it's still tough. The alternatives are either (a) avoiding shared state; (b) strong lifetime management such that you make sure one parent thread owns all of the data that its child threads are going to use; (c) concurrent GC; (d) pretending it's not a problem like Go does and doing stop-the-world GC.
- angersock 15y agoHm... interesting. Looks like we might want to expand our library to have RC with and without atomic ops--that way we can get some of the cleanness of scoped destruction when appropriate without having to go whole-hog ATOMIC RC INVALIDATE ALL THE THINGS when we can getaway with it. Thanks again folks!