Reference counting usually has much higher overheads than garbage collection and is tricky to parallise. It's main advantage is quicker release of memory.
I believe the main feature of ARC is that the user does not need to manually keep reference counts up to date. I heard from people using CPython (which uses reference counting) as a library from C that it's very easy to accidentally forget to update the reference count correctly. With ARC the compiler takes care of it, so there's less opportunity for mistakes. ARC also optimizes away redundant reference updates within a function (Haskell functions are usually small, so I don't know how well that would work). The reason why reference counting is usually slower is: - Say you update a field "f" of object "o" from pointing to "a" to pointing to "b". This entails three memory writes instead of one, because you also need to update the reference counts of "a" and "b". - You also need some extra space to store the reference counts. - You need to take special care to avoid cascades to avoid occasional long pauses. E.g., if an object's reference count goes to zero, that will cause all objects pointed-to by that object to be decreased. This might cause another object's reference count to go to zero etc. - You need a backup tracing collector to collect cycles as you mentioned. There are many optimizations possible, e.g. delayed reference counting, but AFAIK reference counting is in general slower than tracing GC. It does get used in situations where quicker resource release and more predictable GC pauses are more important than absolute performance (or peak throughput). On Sat, Jul 2, 2011 at 16:51, Thomas Davie <[email protected]> wrote: > Hi guys, > > Apple recently announced a new static analysis in Clang called ARC (Automatic > Reference Counting). The idea is to provide what GC provides (zero memory > management code by the programmer), but not to incur the runtime penalty of > having to have the GC run. It seems to be extremely effective in objective-C > land. > > I was wondering if any of the compiler gurus out there could comment on the > applicability of this kind of analysis to Haskell. Dropping the GC and hence > stopping it blocking all threads and killing parallel performance seems like > nirvana. > > The one major problem that's still left with ARC is that it does not solve > the retain cycle problem of reference counting. Programmers must insert a > "weak" keyword to break cycles in their data graphs. Could even this > analysis be automated statically? Could we put up with a language extension > that added this annotation? > > I'd love to hear some comments from people more-experienced-than-I on this. > > Thanks > > Tom Davie > _______________________________________________ > Haskell-Cafe mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Push the envelope. Watch it bend. _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
