> 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.

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.

>Python still doesn't have "proper" multithreading because RC is too slow.

RC speed is not even close to the reason Python doesn't have proper multithreading.

(The GIL, and API/ABI guarantees to third party C-based extensions making it difficult to remove it, is more like it. The GIL was added to aid in RC atomicity - but it's not the speed of RC that's the issue).

> Go has an extremely fast GC that has minimal pauses.

Actually, I've heard that Go sacrificed speed big time to minimise its pauses. Garbage collectors generally face a latency/throughput tradeoff, and I believe Go is no exception.

That said, fast GC with reasonable pauses existed long before Go. I personally know of OCaml and its generational, incremental GC. I expect Go built on that knowledge to find its own sweet spot.

Any memory allocation scheme faces that trade-off, more or less; especially so in a concurrent environment that also employs parallelism.

Precisely. That’s why I was suspicious of this claim that there is a GC out there that is both "extremely fast" and has "minimal pauses". Something’s got to give.

Has anyone tried to build a transpiler from Python to Go?

There are versions of Python without RC: 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

Thanks. It seems that the JyNI project is trying to make a bridge between CPython and Jython, so from that I take that it is somehow possible to have extensions which more or less rely on RC (or at least the C API) while you can use a GC (Java's GC in this case) at the same time.

https://www.jyni.org/

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.

Which one would you say is a relatively better bytecode interpreter? I was looking for one.

One that has a spec and test suite for the implemented VM, for starters.

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.

Not really, only marketing makes RC seem better than tracing GC.

https://github.com/ixy-languages/ixy-languages

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

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=10...

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.

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.

>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.

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.

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.

Swift and Objective-C like performance? No thanks.

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.

How do you deal with cycles in reference counting?

A language can introduce the concept of a strong and weak reference or use a cycle detection algorithm.

Wouldn't cycle detection algorithm basically become a GC under a different name?

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.

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.

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.

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.

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).

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 ;)