In today's CPython with the GIL, it's hard to beat the existing simple
reference counting approach. It's already so cheap, and CPython's
implementation has had a lot of optimization.
I implemented "buffered reference counting" in the Gilectomy because
it's far friendlier to multicore. It added an enormous amount of
overhead. But with enough cores it would eventually become a
performance win.
I'm not optimistic that coalescing would be a win for CPython. On the C
side, reference count change code is written by hand, so hopefully it
already does an intelligent job without redundant reference changes. On
the bytecode side, reference count changes are implicit, so there's
nothing you can optimize. Changing CPython bytecode to make explicit
reference count changes would add so much overhead--the generated
bytecode would be much larger, you'd be dispatching so many reference
count change opcodes--that it's hard to imagine it would be cheaper than
just living with the redundant reference count changes.
My memory is hazy, but IIRC "deferred" reference counting is a clever
scheme in which stack references don't change the reference count, only
heap references do. An object has to have a reference count of zero
/and/ have no active references in the stack in order to be collected.
This seems like a lovely idea, maximizing the best attributes of both
reference counting and tracing garbage collection. However, this would
require walking the stack(s), which we can't do in cross-platform ANSI
C. It would also require a complete overhaul of the C code for CPython
itself (and eventually all extensions), hand-reviewing every reference
count change to decide "is this a heap or a stack reference"?
I don't think there is "low-hanging fruit" left to optimize in CPython's
reference counting scheme. So all that's left are major rewrites like
"deferred" reference counting. Personally I think the future of CPython
is to change completely over to tracing garbage collection. It's so
much friendlier to multicore, which is clearly the future of
programming. I'd rather see efforts in this area directed towards that
goal.
//arry/
On 9/1/20 9:34 AM, Guido van Rossum wrote:
On Tue, Sep 1, 2020 at 9:25 AM Raihan Rasheed Apurbo
<apurb...@gmail.com <mailto:apurb...@gmail.com>> wrote:
Before experimenting can't I ask someone whether relevant
experiments were made or not? if I am not supposed to do that
then I totally agree with you, sir.
I tried asking in python-ideas and one of the replies was "I
gather there have been some experiments along these lines as part
of efforts to remove the GIL. You might like to research them to
find out how much success they've had."
What I can interpret from this reply is there are some experiments
regarding this topic but I don't know where they are. Then I
asked him where could I find them but didn't get any answer to that.
Then how have I got my answers?
I am so sorry if I am asking any inappropriate question here.
Raihan,
Nobody knows the answers to your questions ("can we optimize...",
"where would I face problems...", "is there something I am missing?",
"tell me the factors I should consider").
Your questions are somehow presented as if we *should* know the
answers, and seem to insinuate that we should have investigated the
techniques you mention. The answer to this is that we are doubtful
that it will be easy to implement them in a fully backwards compatible
way (and you'd be surprised how important backwards compatibility is).
The only thing I personally know about this topic is that Larry
Hastings attempted a more sophisticated approach to multi-threaded
reference counting without the GIL, and came up short despite putting
a lot of effort in it. You should probably do some Googling on
Gilectomy and find Larry's various annual updates. That is presumably
what that python-ideas answer was referring to.
Good luck.
--
--Guido van Rossum (python.org/~guido <http://python.org/~guido>)
/Pronouns: he/him //(why is my pronoun here?)/
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/XSP4NZDT2ZQVSAQHRN4Z6HSXGCWVYZ3Q/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/YJDRVOUSRVGCZTKIL7ZUJ6ITVWZTC246/
Code of Conduct: http://python.org/psf/codeofconduct/
