CPython without a global interpreter lock

Posted Aug 11, 2023 15:30 UTC (Fri) by Karellen (subscriber, #67644)
In reply to: CPython without a global interpreter lock by alkbyby
Parent article: CPython without a global interpreter lock

Isn't ref-counting a lot more performant than GC? If you can ref-count the majority of the easy cases, and leave GC to only mop up the smaller set of hard cases which remain, isn't that going to be a big win?

CPython without a global interpreter lock

Posted Aug 11, 2023 16:10 UTC (Fri) by alkbyby (subscriber, #61687) [Link]

I think that is one of bigger debates in our trade (e.g. recall famous paper by Boehm from as early as 90s). But as noted in this article too, refcounting is okay for fully single threaded cases (arguably, even that can be debated). But when it comes to multi-threaded cases, it quickly becomes burden. Especially if you compare with modern advanced GCs of today.

So, IMHO refcounting was and is wrong choice (for python-like use cases; e.g. kernel-space is a different matter).

(Not so) fun fact: gcc's libstdc++ still has this horrible "optimization" where shared_ptr bits detect at runtime if multi-threading is active inlined at ~every place share_ptr is copied. And compiler adds this run-time check and both single-threaded and multi-thread "atomic-ful" refcounting codes everywhere! Quick godbolt proof: https://godbolt.org/z/o9b9hxfMP

Of course this is me cherry-picking one annoying arguably performance bug in gcc. But imho it adds nicely to the topic of: "no, refcounting is not anywhere as straightforward as people tend to think".