[Python-Dev] Re: killing static types (for sub-interpreters?)

[Jim J. Jewett]

Ronald Oussoren wrote:
> > On 28 Apr 2020, at 20:38, Jim J. Jewett jimjjew...@gmail.com wrote:
> > Why do sub-interpreters require (separate and) heap-allocated types?
> > It seems types that are statically allocated are a pretty good use for 
> > immortal
> > objects, where you never change the refcount ... and then I don't see why 
> > you need more
> > than one copy.

>  …  One reason is type.__subclasses__(), that returns a list of
> all subclasses and when a type is shared between sub-interpreters the return 
> value might
> refer to objects in another interpreter. That could be fixed by another level 
> of
> indirection I guess.  But extension types could contain other references to 
> Python
> objects, and it is a lot easier to keep track of which subinterpreter those 
> belong to when
> every subinterpreter has its own copy of the type.

So the problem is that even static types often have mutable (containers of) 
references back 
into the heap, and with multiple interpreters, these references would have to 
be made 
per-interpreter?

If I'm not still missing something, then that could get ugly, but doesn't seem 
any worse
than other things sub-interpreters have to multiply.

>  ... “Never changing the refcount” could be expensive

Absolutely!  That has always been the problem in the past.

> in its own right, that adds a branch to every invocation of Py_INCREF and 
> Py_DECREF.  See
> also the benchmark data in  https://bugs.python.org/issue40255> 
> (which contains a patch that disables refcount updates for arbitrary objects).

The updated patch shows that not having to write the memory (and invalidate 
caches, etc) is enough to 
make up for the extra testing.  https://bugs.python.org/msg366605  Obviously, 
that might not hold up
on other machines, etc., but it is already good enough to be interesting, and 
there is room for additional
experimentation.
___
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/X5GM3TSGD4XR3U6OGU533232FPKGB2LZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: killing static types (for sub-interpreters?)

[Steve Dower]

On 28Apr2020 2006, Steve Dower wrote:
(For those who aren't following it, there's a discussion with a patch 
and benchmarks going on at https://bugs.python.org/issue40255 about 
making objects individually immortal. It's more focused around 
copy-on-write, rather than subinterpreters, but the benefits apply to 
both.)


More precisely, the benefits are different, but the implementation 
provides each to each scenario.


I also want to draw attention to one specific post 
https://bugs.python.org/issue40255#msg366577 where some additional 
changes (making more objects immortal) brought the benchmarks well back 
within error margins, after initial checks found more than 10% 
regression on about 1/4 of the performance suite.


Cheers,
Steve
___
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/VGIO4GB25DEDJ5FXOUBJV5JMKFDDD5JY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: killing static types (for sub-interpreters?)

[Steve Dower]

If the object is going to live until the "end of time" 
(process/runtime/whatever) then there'll never be a need to deallocate 
it, and so there's no point counting how many references exist (and 
ditto for anything that it references).


Currently, statically allocated types include references to 
heap-allocated objects, and since different interpreters may use 
different heaps (via different allocators), this means they can't share 
the static types either. These references are for freelists, weak 
references, and some others that I forget but apparently make it 
unfixable. Those with a __dict__ object also need to be per-interpreter.


If statically allocated types were truly constant, that would be great! 
Then they could be freely reused. The same applies for many of our 
built-in non-container types too, in my opinion (and my goal would be to 
make code objects fully shareable, so you don't have to recompile/reload 
them for each new interpreter).


(For those who aren't following it, there's a discussion with a patch 
and benchmarks going on at https://bugs.python.org/issue40255 about 
making objects individually immortal. It's more focused around 
copy-on-write, rather than subinterpreters, but the benefits apply to both.)


Cheers,
Steve

On 28Apr2020 1949, Paul Ganssle wrote:

I don't know the answer to this, but what are some examples of objects
where you never change the refcount? Are these Python objects? If so,
wouldn't doing something like adding the object to a list necessarily
change its refcount, since the list implementation only knows, "I have a
reference to this object, I must increase the reference count", and it
doesn't know that the object doesn't need its reference count changed?

Best,
Paul

On 4/28/20 2:38 PM, Jim J. Jewett wrote:

Why do sub-interpreters require (separate and) heap-allocated types?

It seems types that are statically allocated are a pretty good use for immortal 
objects, where you never change the refcount ... and then I don't see why you 
need more than one copy.

___
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/MKMGRHYKA2WLQ6UPLJQS5TXCC7CFEN43/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: killing static types (for sub-interpreters?)

[Ronald Oussoren via Python-Dev]

> On 28 Apr 2020, at 20:38, Jim J. Jewett  wrote:
> 
> Why do sub-interpreters require (separate and) heap-allocated types?  
> 
> It seems types that are statically allocated are a pretty good use for 
> immortal objects, where you never change the refcount ... and then I don't 
> see why you need more than one copy.

I guess it depends…  One reason is type.__subclasses__(), that returns a list 
of all subclasses and when a type is shared between sub-interpreters the return 
value might refer to objects in another interpreter. That could be fixed by 
another level of indirection I guess.  But extension types could contain other 
references to Python objects, and it is a lot easier to keep track of which 
subinterpreter those belong to when every subinterpreter has its own copy of 
the type.  

If subinterpreters get their own GIL maintaining the refcount is another reason 
for not sharing types between subinterpreters.  “Never changing the refcount” 
could be expensive in its own right, that adds a branch to every invocation of 
Py_INCREF and Py_DECREF.  See also the benchmark data in 
>  
(which contains a patch that disables refcount updates for arbitrary objects).

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
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/DAKZI7352EWIMJ7Y2YLHPCHJST7DIZWB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: killing static types (for sub-interpreters?)

[Paul Ganssle]

I don't know the answer to this, but what are some examples of objects
where you never change the refcount? Are these Python objects? If so,
wouldn't doing something like adding the object to a list necessarily
change its refcount, since the list implementation only knows, "I have a
reference to this object, I must increase the reference count", and it
doesn't know that the object doesn't need its reference count changed?

Best,
Paul

On 4/28/20 2:38 PM, Jim J. Jewett wrote:
> Why do sub-interpreters require (separate and) heap-allocated types?  
>
> It seems types that are statically allocated are a pretty good use for 
> immortal objects, where you never change the refcount ... and then I don't 
> see why you need more than one copy.
> ___
> 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/S674C2BJ7NHKB3SOJF4VFRXVNQDNSCHP/
> Code of Conduct: http://python.org/psf/codeofconduct/



signature.asc
Description: OpenPGP digital signature
___
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/J64VIJPXBCR7DQPDFSZWTLRVIYGCXYPF/
Code of Conduct: http://python.org/psf/codeofconduct/