3 ms·

You can write a reference counter in three short lines of code that works the same as shared_ptr<T> or Swift. A modern automatic garbage collector requires a th

You can write a reference counter in three short lines of code that works the same as shared_ptr<T> or Swift. A modern automatic garbage collector requires a threading library plus tens of thousands of lines of intricate code. We're not comparing like with like here.

prodigal_erik 10y ago
The three line version is really easy to write. And every time you assign to a pointer, it requires uncached atomic updates to the refcounts of the old and new objects, which is staggeringly expensive compared to a block of code that can go unused for minutes at a time. And all it gets you is learning that a small piece of memory is available slightly sooner, but you'll probably want to coalesce your free memory anyway for better locality.
- WildUtah 10y ago
  I hope that the 100-man years of top engineers version has some benefits over the 3-line newbie approach.
- lokedhs 10y ago
  People tend to think that refcounting must be faster than a tracing GC because you don't have to scan the memory. The second half of the previous sentence is true, but what they forget is that refcounting needs to do a lot of things that a GC doesn't have to: Like you said, need to update the reference every time it's moved. malloc becomes much slower, compared to a GC language (with a compacting GC) where malloc is effectively just a single add instruction. free also needs to do a lot of bookkeeping while the GC language doesn't need to do anything. Multithreading introduces another set of issues when dealing with refcounting that is not a problem with a GC.
  - je42 10y ago
    Multithreading also introduces issues for GC. It needs to stop all threads. If you look at how much work has been delivered towards the GC's of for example JVM, Go and V8. It is a really tough problem to get right for all application types. Reference counting is very predictable. And if you see a bottle neck you can start fixing it. And with ARC (Swift/ObjC) you get even compiler support to optimize all ref counting administration. Further malloc doesn't have anything to do with ref counting as ref counting sits on top if it. Further, GC languages also need to do book keeping: Generations and Compaction.
    - lokedhs 10y ago
      That is true, but only during GC itself. Refcounting causes these issues every time the reference is copied. For malloc, the benefit with a compacting GC is that the free memory will always be in a contiguous segment. Therefore, a malloc operating is similar to a stack allocation in that all you need to do is to move a single pointer. Without a compacting GC, you need to search a tree whenever you want to allocate memory.

prodigal_erik 10y ago

The three line version is really easy to write. And every time you assign to a pointer, it requires uncached atomic updates to the refcounts of the old and new objects, which is staggeringly expensive compared to a block of code that can go unused for minutes at a time. And all it gets you is learning that a small piece of memory is available slightly sooner, but you'll probably want to coalesce your free memory anyway for better locality.

WildUtah 10y ago
I hope that the 100-man years of top engineers version has some benefits over the 3-line newbie approach.
lokedhs 10y ago
People tend to think that refcounting must be faster than a tracing GC because you don't have to scan the memory. The second half of the previous sentence is true, but what they forget is that refcounting needs to do a lot of things that a GC doesn't have to: Like you said, need to update the reference every time it's moved. malloc becomes much slower, compared to a GC language (with a compacting GC) where malloc is effectively just a single add instruction. free also needs to do a lot of bookkeeping while the GC language doesn't need to do anything. Multithreading introduces another set of issues when dealing with refcounting that is not a problem with a GC.
- je42 10y ago
  Multithreading also introduces issues for GC. It needs to stop all threads. If you look at how much work has been delivered towards the GC's of for example JVM, Go and V8. It is a really tough problem to get right for all application types. Reference counting is very predictable. And if you see a bottle neck you can start fixing it. And with ARC (Swift/ObjC) you get even compiler support to optimize all ref counting administration. Further malloc doesn't have anything to do with ref counting as ref counting sits on top if it. Further, GC languages also need to do book keeping: Generations and Compaction.
  - lokedhs 10y ago
    That is true, but only during GC itself. Refcounting causes these issues every time the reference is copied. For malloc, the benefit with a compacting GC is that the free memory will always be in a contiguous segment. Therefore, a malloc operating is similar to a stack allocation in that all you need to do is to move a single pointer. Without a compacting GC, you need to search a tree whenever you want to allocate memory.