Making Python 3 more attractive
Making Python 3 more attractive
Posted Apr 17, 2015 0:30 UTC (Fri) by wahern (subscriber, #37304)In reply to: Making Python 3 more attractive by Cyberax
Parent article: Making Python 3 more attractive
Fair enough. I don't use Python :)
So I guess the paper is slightly more relevant. But the comment that only a super-optimized RC framework could match a mark & sweep collector simply doesn't square with what the paper actually says. The paper only shows algorithmic equivalency between a) automated RC with cycle collection and b) tracing collectors. In fact, it tends to show that such systems should provide comparable performance when similarly optimized.
"This in turn allowed us to demonstrate that all high-performance garbage collectors are in fact hybrids of tracing and reference counting techniques. This explains why highly optimized tracing and reference counting collectors have surprisingly similar performance characteristics."
This is the Nth time I've seen that paper posted to try to argue that tracing collectors are faster than RC. It's some kind of horrible meme. A couple of other times it's been posted to try to argue that tracing collectors are faster than manual (and minimal, in that the entire graph of objects is rarely subject to independent lifetime management) reference counting in C and similar languages with non-automated memory management. In all cases I don't even think the original posters bothered reading the paper, because the paper 1) only concludes that performance is algorithmically equivalent, and alludes to benchmarks which show equivalent performance in real-world implementations, rather than showing that tracing collector implementations tend to be faster; and 2) is irrelevant to collection frameworks that don't automate as much as tracing collectors.
Posted Apr 17, 2015 0:44 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
So in practice quite often non-atomic reference counters might be faster than simple mark&sweep GC.
Posted Apr 17, 2015 1:18 UTC (Fri)
by samlh (subscriber, #56788)
[Link] (1 responses)
I agree that mark/sweep collectors are not universally the best option, for reasons of memory overhead, non-determinism, complexity, and so forth.
However, in the case of python, I am more willing to make the claim that mark/sweep collection would be beneficial performance-wise. I am basing this on PyPy's previous experimentation with different collection algorithms, including reference counting (with cycle collection, as required by Python). Their experience has led them, like the JS folk, to use a single-generational mark/sweep collector.
Regardless of the performance, though, I doubt that cPython should ever switch, simply due to the benefits of a stable c api. The answer to lack of Python 3 adoption is unlikely to be further breaking changes... though I admit I have no idea what is the answer.
Posted Apr 17, 2015 1:26 UTC (Fri)
by samlh (subscriber, #56788)
[Link]
Making Python 3 more attractive
There's a catch, though. In real Python programs cycles are fairly rare and most of the objects are deallocated by the reference counting destructors.
Making Python 3 more attractive
Making Python 3 more attractive
PyPy uses a single nursery generation and a tenured generation.
Spidermonkey (Firefox) is has some generational scheme (I'm fairly sure nursery+tenured).
I'm unsure of how V8 and Webkit have their gc structured.
