[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

2020-09-02 Thread Raihan Rasheed Apurbo
Thank you sir for directing me to Gilectomy. I will definitely take a look and 
that and try to design my own experimentations. 

I definitely could have asked for direction in a better way. I could have asked 
in a better approach. Thanks for pointing that out as well.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/BF37I56A4C2ZJQYSPFPQYXHBDYA3HUDE/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

2020-09-02 Thread Raihan Rasheed Apurbo
Thank you, sir. Guido already mentioned it so I was going to search google 
about it. Thanks for your direct link as well. I really appreciate it. I will 
surely look into that. :)
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/G4GZKEP2REHERMZPEWVMHZXW45TUTES2/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

2020-09-02 Thread Eric V. Smith



On 9/2/2020 1:23 PM, Raihan Rasheed Apurbo wrote:

Thank you, sir. Guido already mentioned it so I was going to search google 
about it. Thanks for your direct link as well. I really appreciate it. I will 
surely look into that. :)


No problem. It would also help if you included a little context when you 
replied to messages. It's not clear who you're responding to here 
(although I think it's me).


Eric
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/AQ62K7EDMLEXCPZEGSOUVQGTHFRSC3XO/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

2020-09-02 Thread Raihan Rasheed Apurbo
Sorry, Eric. V. Smith. I don't know how to quote someone like everyone is 
doing. I am new to mailman . I am working on it though.
Thanks.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/AMFQHCOBDBDA2AXSDUHXV5PYEW4HFSJX/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

2020-09-02 Thread Raihan Rasheed Apurbo
Thank you Larry Hastings for your wonderful detailed answer. Just the answer I 
was looking for. I am trying to work on memory management in python. CPython 
reference counting is very hard to modify. Before I start implementing 
something I just wanted to know whether anybody has tried similar things before 
and wanted to know their experience on this just so I don't end up implementing 
something which already was tried before me. 

Now that I know your thoughts on this. It would be helpful for me to find my 
way and decide where to put effort. I am so grateful for your answer. Thank 
you, sir. I apologize again if my way of asking was rude.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/IF6GSRYRNVMYVYARUHBVWGWENAGWKXSI/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

2020-09-02 Thread Jim J. Jewett
Raihan Rasheed Apurbo wrote:
> In CPython we have reference counting. My question is can we optimize current 
> RC using
> strategies like Deferred RC and Coalescing?

You might also look at some of the older attempts to remove reference counting 
entirely in favor of (usually) the Boehm tracing collector.  The "problem" is 
that adding 1 to an integer that is already in cache is pretty quick.  The same 
goes for subtracting 1.  So to beat the current system, you need something very 
fast *and* you need to take out some cost that isn't directly part of reference 
counting.  

If you're assuming multiple threads (or processes) on different cores, that is 
possible.  You know about the Gilectomy by now.  I suspect that splitting the 
reference count away from the object itself could also be profitable, as it 
means the cache won't have to be dirtied (and flushed) on read access, and can 
keep Copy-On-Write from duplicating pages.  On the other hand, it also means 
that you'll (eventually, after your optimization strategies) have to issue 
extra loads for the reference count, instead of getting it into cache for free 
when you load the data.

> If no then where would I face problems if I try to implement these sorts of 
> strategies?

The current system is really very fast, particularly in a single-threaded 
environment.  You probably won't see enough gains to make up for the complexity 
unless you do also reorganize memory.  That isn't easy to do in incremental 
steps, or in a backwards-compatible way.  But looking at how PyPy organizes its 
memory models may provide a rough map of something that works.  (Or warn you of 
what doesn't work, if they say "can't use this model when using extension 
modules.")

> These strategies all depend on the concept that we don't need the exact value 
> of
> reference count all the time. So far in my observation, we only need exact 
> value before
> running a cycle collector.  

We also need to be sure the estimate is never too low, or at least that it 
never goes negative, and that it never hits 0 when it shouldn't.  Being too 
high is fine, but it may lead to using a surprisingly large amount of extra 
memory, and breaking out of cache more often.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/CRRUXXHEULAH4YXMYOJNZEPU5U6LUUSH/
Code of Conduct: http://python.org/psf/codeofconduct/