7 ms·

We have gone full circle with GCs. It was reference counting in the 80s and 90s. And then tracing GC people stepped in. "Reference counting is worse of both wo

We have gone full circle with GCs. It was reference counting in the 80s and 90s. And then tracing GC people stepped in. "Reference counting is worse of both worlds. It's slower than GC because all these memory have to be touched!" But real life experience continues to show ref counting doing better. And GC users pre allocating object pool to avoid GC pauses. Proponents still in denial. "What if a large object is deleted? That will also create GC pause like delay." And now here we stand. Back to reference counting.

kungito 5y ago
We have not gone full circle. We are just expanding into various scenarios where a gc language is preferable to non gc language and vice versa. There will never be a perfect compiler nor do we always want to do everything manually.
chronogram 5y ago
Ever since Java became immensely popular GC has been just as popular, but that didn't mean reference counting ever went away. They're branching paths and different tools and more people than ever before pick and choose what to use for the job. No circle was ever made.
- habibur 5y ago
  Right Java made GC popular. And right now Rust is making reference counting, borrow-owner popular. This is what I am observing. That languages get popular is no surprise. But what was a little bit surprising for me was that the tech the language uses gets spread and popular all over -- outside of that language as long as that language stays popular. I right now am think automatic reference counting is the way to go. In a sense C++ RAII is also ARC. But a compiler level support is better.
  - pjmlp 5y ago
    Swift and Objective-C like performance? No thanks.
raverbashing 5y ago
I agree. "Garbage collecting", so, you mean, you're leaving garbage around then? Why? With RC you're acting on the deallocation as soon as you are allowed to. Sure, you don't need to actually deallocate at that time, but you're acting upon it. "Oh but what about loops" well, you can work around those (and they are rare). My point is not that GCs are not useful. My point is that there is a better way of dealing with allocations if you know your object is not used anymore and not just treating memory as infinite.
- p_l 5y ago
  And then you get some pretty hilarious pauses and stuttering because such naive refcount system suck on all metrics other than simplicity of code (and even that is arguable). And despite what some people think, malloc/free are not O(1) free lunch.
  - raverbashing 5y ago
    Well, naive code is going to suck, be it RC or GC > And despite what some people think, malloc/free are not O(1) free lunch Of course. Be it through a GC allocator or not. If you're at the point where the allocator is giving you trouble then GC/RC is the least of your problems ;)
  - zozbot234 5y ago
    You can use arenas for the cases where you really can't do without delayed/batched deallocation. But deterministic deallocation as provided by RC is a very good default for many cases, including where low-latency is a goal.
    - p_l 5y ago
      RC is not deterministic. That's the whole thing - when you free a refcounted object, you do not deterministically know how long is it going to take, and on systems that try to avoid RC-induced pauses, you don't get to know when the memory is going to be released. If you want to talk determinism, you need to actually invest into deterministic behaviour - something that either requires dropping dynamic memory allocation altogether, or tends to go for GC with known determinism guarantees (for example, IBM Metronome).
chronial 5y ago
Which real life experience are you referring to? Go has an extremely fast GC that has minimal pauses. Python still doesn't have "proper" multithreading because RC is too slow. The problem with rc is not memory access but synchronization.
- amelius 5y ago
  Has anyone tried to build a transpiler from Python to Go?
  - p_l 5y ago
    Unfortunately, the real test of "is this language proper python" is "it behaves exactly as the horrible bytecode interpreter in PyEvalFrameEx C function". So it's hard to make alternative implementations that don't die.
    - habibur 5y ago
      Which one would you say is a relatively better bytecode interpreter? I was looking for one.
      - p_l 5y ago
        One that has a spec and test suite for the implemented VM, for starters.
  - chronial 5y ago
    There are versions of Python without RC: https://www.python.org/download/alternatives/ https://www.python.org/download/alternatives/. There is no doubt that Python would be better off without RC, the problem is that Python extensions rely on RC. So CPython (the main python implemenation) can't just do the switch. If you want more information about this topic, there is a nice talk by Larry Hastings: https://www.youtube.com/watch?v=pLqv11ScGsQ https://www.youtube.com/watch?v=pLqv11ScGsQ
    - 5y ago
flohofwoe 5y ago
> But real life experience continues to show ref counting doing better. Hmm... not in my experience at least, for instance Apple's ARC (which should be much better than "dumb" shared_ptr refcounting because the compiler does some static analysis and drops redundant retain/release operations) still can have a shockingly high runtime overhead and requires careful manual tweaking and general handholding to the point where the traditional manual memory management results in simpler code, at least in hot code paths. Now GCs may well be worse, but performance-wise they really can't be much worse than ARC. ARC may sometimes prevent unpredictable GC spikes, but only by spreading out the same (or worse) cost along the timeline (which is at least something, but many GCs simply haven't been designed for the "prevent spikes" requirement). There simply is no silver bullet for dynamic memory management, at least if both memory usage and performance matters.
xxs 5y ago
>real life experience continues to show ref counting doing better What experiences would be that? "GC pauses" exist in stop-the-world garbage collector's phase. If you need a concurrent one - they exist just as well.
deepsun 5y ago
How do you deal with cycles in reference counting?
- hgs3 5y ago
  A language can introduce the concept of a strong and weak reference or use a cycle detection algorithm.
  - deepsun 5y ago
    Wouldn't cycle detection algorithm basically become a GC under a different name?
    - hgs3 5y ago
      RC is GC and whether a cycle detection algorithm uses tracing depends upon the algorithm itself. Unlike traditional tracing, a cycle detection algorithm can leverage knowledge of the reference counter which opens new possibilities. In fact, cycle detection doesn't necessarily need to be run at all - only in the ambiguous cases where RC alone isn't enough. When a code path does necessitate cycle detection, the algorithm could run immediately and, depending upon the nature of the cycle/how localized it is, the runtime could cache the knowledge for next time. Even where it must always be run, the pauses are smaller and deterministic which means it avoids the long/unpredictable/sporadic pause times tracing collectors are infamous for.
MaxBarraclough 5y ago
Borrower-checking is a significant development over traditional manual memory management, rendering various categories of error impossible. Before borrower-checking, we could really only do this by using GC.
pjmlp 5y ago
Not really, only marketing makes RC seem better than tracing GC. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages https://forums.swift.org/t/swift-performance/28776 https://forums.swift.org/t/swift-performance/28776 It is no wonder that Swift 5.5 brings aggressive compiler optimisations that can even break code that naively relies on basic ARC behaviour. RC also has pauses, pretty lengthy ones with cascade deletions, and can even lead to stack overflows. "CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default"" https://youtu.be/JfmTagWcqoE https://youtu.be/JfmTagWcqoE Which is why as GC algorithm reference counting is only for toy implementations. Any reference counting implementation that cares about performance in multicore environments is almost indistinguishable from a tracing GC implementation. In fact, C++/WinRT, uses background threads to diminish the performance impact of calling destructor and cascading deletions. https://devblogs.microsoft.com/oldnewthing/20191018-00/?p=103010 https://devblogs.microsoft.com/oldnewthing/20191018-00/?p=10...
- habibur 5y ago
  Game developers tell a different story. But you can find on net whatever you seek, whatever you are looking for. > Which is why as GC algorithm reference counting is only for toy implementations. That's what I heard from last decade. And then experience has outgrown likes or dislikes.
  - pjmlp 5y ago
    The game developers that use Unreal C++? The fact that Swift and Objective-C get outperformed in any research about automatic memory management is quite real, not urban myths.

kungito 5y ago

We have not gone full circle. We are just expanding into various scenarios where a gc language is preferable to non gc language and vice versa. There will never be a perfect compiler nor do we always want to do everything manually.

chronogram 5y ago

Ever since Java became immensely popular GC has been just as popular, but that didn't mean reference counting ever went away. They're branching paths and different tools and more people than ever before pick and choose what to use for the job. No circle was ever made.

habibur 5y ago
Right Java made GC popular. And right now Rust is making reference counting, borrow-owner popular. This is what I am observing. That languages get popular is no surprise. But what was a little bit surprising for me was that the tech the language uses gets spread and popular all over -- outside of that language as long as that language stays popular. I right now am think automatic reference counting is the way to go. In a sense C++ RAII is also ARC. But a compiler level support is better.
- pjmlp 5y ago
  Swift and Objective-C like performance? No thanks.

raverbashing 5y ago

I agree. "Garbage collecting", so, you mean, you're leaving garbage around then? Why? With RC you're acting on the deallocation as soon as you are allowed to. Sure, you don't need to actually deallocate at that time, but you're acting upon it. "Oh but what about loops" well, you can work around those (and they are rare). My point is not that GCs are not useful. My point is that there is a better way of dealing with allocations if you know your object is not used anymore and not just treating memory as infinite.

p_l 5y ago
And then you get some pretty hilarious pauses and stuttering because such naive refcount system suck on all metrics other than simplicity of code (and even that is arguable). And despite what some people think, malloc/free are not O(1) free lunch.
- raverbashing 5y ago
  Well, naive code is going to suck, be it RC or GC > And despite what some people think, malloc/free are not O(1) free lunch Of course. Be it through a GC allocator or not. If you're at the point where the allocator is giving you trouble then GC/RC is the least of your problems ;)
- zozbot234 5y ago
  You can use arenas for the cases where you really can't do without delayed/batched deallocation. But deterministic deallocation as provided by RC is a very good default for many cases, including where low-latency is a goal.
  - p_l 5y ago
    RC is not deterministic. That's the whole thing - when you free a refcounted object, you do not deterministically know how long is it going to take, and on systems that try to avoid RC-induced pauses, you don't get to know when the memory is going to be released. If you want to talk determinism, you need to actually invest into deterministic behaviour - something that either requires dropping dynamic memory allocation altogether, or tends to go for GC with known determinism guarantees (for example, IBM Metronome).

chronial 5y ago

Which real life experience are you referring to? Go has an extremely fast GC that has minimal pauses. Python still doesn't have "proper" multithreading because RC is too slow. The problem with rc is not memory access but synchronization.

amelius 5y ago
Has anyone tried to build a transpiler from Python to Go?
- p_l 5y ago
  Unfortunately, the real test of "is this language proper python" is "it behaves exactly as the horrible bytecode interpreter in PyEvalFrameEx C function". So it's hard to make alternative implementations that don't die.
  - habibur 5y ago
    Which one would you say is a relatively better bytecode interpreter? I was looking for one.
    - p_l 5y ago
      One that has a spec and test suite for the implemented VM, for starters.
- chronial 5y ago
  There are versions of Python without RC: https://www.python.org/download/alternatives/ https://www.python.org/download/alternatives/. There is no doubt that Python would be better off without RC, the problem is that Python extensions rely on RC. So CPython (the main python implemenation) can't just do the switch. If you want more information about this topic, there is a nice talk by Larry Hastings: https://www.youtube.com/watch?v=pLqv11ScGsQ https://www.youtube.com/watch?v=pLqv11ScGsQ
  - 5y ago

flohofwoe 5y ago

> But real life experience continues to show ref counting doing better. Hmm... not in my experience at least, for instance Apple's ARC (which should be much better than "dumb" shared_ptr refcounting because the compiler does some static analysis and drops redundant retain/release operations) still can have a shockingly high runtime overhead and requires careful manual tweaking and general handholding to the point where the traditional manual memory management results in simpler code, at least in hot code paths. Now GCs may well be worse, but performance-wise they really can't be much worse than ARC. ARC may sometimes prevent unpredictable GC spikes, but only by spreading out the same (or worse) cost along the timeline (which is at least something, but many GCs simply haven't been designed for the "prevent spikes" requirement). There simply is no silver bullet for dynamic memory management, at least if both memory usage and performance matters.

xxs 5y ago

>real life experience continues to show ref counting doing better What experiences would be that? "GC pauses" exist in stop-the-world garbage collector's phase. If you need a concurrent one - they exist just as well.

deepsun 5y ago

How do you deal with cycles in reference counting?

hgs3 5y ago
A language can introduce the concept of a strong and weak reference or use a cycle detection algorithm.
- deepsun 5y ago
  Wouldn't cycle detection algorithm basically become a GC under a different name?
  - hgs3 5y ago
    RC is GC and whether a cycle detection algorithm uses tracing depends upon the algorithm itself. Unlike traditional tracing, a cycle detection algorithm can leverage knowledge of the reference counter which opens new possibilities. In fact, cycle detection doesn't necessarily need to be run at all - only in the ambiguous cases where RC alone isn't enough. When a code path does necessitate cycle detection, the algorithm could run immediately and, depending upon the nature of the cycle/how localized it is, the runtime could cache the knowledge for next time. Even where it must always be run, the pauses are smaller and deterministic which means it avoids the long/unpredictable/sporadic pause times tracing collectors are infamous for.

MaxBarraclough 5y ago

Borrower-checking is a significant development over traditional manual memory management, rendering various categories of error impossible. Before borrower-checking, we could really only do this by using GC.

pjmlp 5y ago

Not really, only marketing makes RC seem better than tracing GC. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages https://forums.swift.org/t/swift-performance/28776 https://forums.swift.org/t/swift-performance/28776 It is no wonder that Swift 5.5 brings aggressive compiler optimisations that can even break code that naively relies on basic ARC behaviour. RC also has pauses, pretty lengthy ones with cascade deletions, and can even lead to stack overflows. "CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default"" https://youtu.be/JfmTagWcqoE https://youtu.be/JfmTagWcqoE Which is why as GC algorithm reference counting is only for toy implementations. Any reference counting implementation that cares about performance in multicore environments is almost indistinguishable from a tracing GC implementation. In fact, C++/WinRT, uses background threads to diminish the performance impact of calling destructor and cascading deletions. https://devblogs.microsoft.com/oldnewthing/20191018-00/?p=103010 https://devblogs.microsoft.com/oldnewthing/20191018-00/?p=10...

habibur 5y ago
Game developers tell a different story. But you can find on net whatever you seek, whatever you are looking for. > Which is why as GC algorithm reference counting is only for toy implementations. That's what I heard from last decade. And then experience has outgrown likes or dislikes.
- pjmlp 5y ago
  The game developers that use Unreal C++? The fact that Swift and Objective-C get outperformed in any research about automatic memory management is quite real, not urban myths.