[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

Guido wrote: > Did Larry Hastings ever publish his experience with separating the > refcount for his Gilectomy project? I believe he told us at a sprint or > language summit that he had this working, with much effort, but hadn't > managed to make it faster than the existing refcounting

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

Did Larry Hastings ever publish his experience with separating the refcount for his Gilectomy project? I believe he told us at a sprint or language summit that he had this working, with much effort, but hadn't managed to make it faster than the existing refcounting implementation yet. On Tue, Jun

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

On Tue, 16 Jun 2020 09:34:59 +0100 Jonathan Fine wrote: > > I've changed my opinion. I doubt that there's an easy win here. But I > suspect that there is a win that is worth having. I'll now go away and > think about things for a while. This is a good idea. An even better idea, for people who

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

Many thanks to all for your useful and interesting contributions. They've helped me, and given me a lot to think about. It's clear that there are several related or overlapping issues. Here are some comments. 1. A major problem is to speed-up A, without slowing B. In other words, how to avoid

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

On 16/06/20 4:16 am, Barry Scott wrote: even unchanging objects get modified by a ref count inc/dec cycle and then the page that the object is in is copy-on-write'ed. End result is that a children share no pages with the parent. I wonder if it's worth trying to do anything about that? Like

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

> On 15 Jun 2020, at 20:48, Christopher Barker wrote: > > On Mon, Jun 15, 2020 at 9:21 AM Barry Scott > wrote: > The problem is when you fork a python process. > > Each of the child processes you would hope shared the state of the > parent that is not being

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

On Mon, Jun 15, 2020 at 9:21 AM Barry Scott wrote: > The problem is when you fork a python process. > > Each of the child processes you would hope shared the state of the > parent that is not being changed. But because of ref counting > even unchanging objects get modified by a ref count inc/dec

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

> On 14 Jun 2020, at 22:59, Ben Rudiak-Gould wrote: > > There isn't really any contention for these memory locations in > CPython as it stands because only one interpreter thread can run at a > time. The only time a cache handoff is needed is during a thread > switch when the new thread is

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

-Original Message- From: Greg Ewing Sent: 15 June 2020 07:23 To: python-ideas@python.org Subject: [Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted On 15/06/20 5:11 pm, Steve Barnes wrote: > Of course if we had a NaN value for integers,

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

On Mon, Jun 15, 2020 at 06:22:34PM +1200, Greg Ewing wrote: > On 15/06/20 5:11 pm, Steve Barnes wrote: > > >Of course if we had a NaN value for integers, int('NaN'), then we could > >just set the initial count to it and since NaN - anything = NaN all would > >be golden. > > Or we could use

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

On 15/06/20 5:11 pm, Steve Barnes wrote: Of course if we had a NaN value for integers, int('NaN'), then we could just set the initial count to it and since NaN - anything = NaN all would be golden. Or we could use floating-point reference counts... -- Greg

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

-Original Message- From: Ben Rudiak-Gould Sent: 14 June 2020 22:59 To: Jonathan Fine Cc: python-ideas Subject: [Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted There isn't really any contention for these memory locations in CPython as it

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

There's a PR for this: "Immortal instances", by Eddie Elizondo (Facebook). Github PR: https://github.com/python/cpython/pull/19474 Bug Report: https://bugs.python.org/issue40255 On Sat, Jun 13, 2020 at 3:48 AM Jonathan Fine wrote: > Hi > > Here's something that might make code run quicker. The

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

There isn't really any contention for these memory locations in CPython as it stands because only one interpreter thread can run at a time. The only time a cache handoff is needed is during a thread switch when the new thread is scheduled on a different core, which is pretty rare (at CPU

[Python-ideas] Re: For quicker execution, don't refcount objects that can't be deleted

well, the problem is that the code calling the refcount doen'st know those objects are "special", and thus need to call Py_INCREF and Py_DECREF anyway. So are you suggesting that Py_INCREF and Py_DECREF do a check to see if the objects is "special" in this way, and not actually change the