[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

STINNER Victor added the comment: > On such platforms, the `PyGet_Foo` API can be on equal footing with the > legacy `Py_Foo` statics, i.e. both would do the same thing. That's how I've > done it in my experiment. The obvious problem is that on platforms without > compiler support for TLS,

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Kuba Sunderland-Ober added the comment: I'm looking very much forward to isolated subinterpreters and thus the per-subinterpreter GIL, as I've been keeping a private exploratory project where I had to make them work. Here are my thoughts: 1. Any sort of reference count on heavily used

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Change by Mark Dickinson : -- nosy: -mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Change by h-vetinari : -- nosy: +h-vetinari ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Change by Mateusz Loskot : -- nosy: +mloskot ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

STINNER Victor added the comment: Raymond Hettinger: "Shouldn't this wait to see if the subinterpreters PEP is approved? Because if it isn't, then no chance should be made. We shouldn't change something this fundamental without good cause." I agree that we reached a point where a PEP is

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Raymond Hettinger added the comment: Shouldn't this wait to see if the subinterpreters PEP is approved? Because if it isn't, then no chance should be made. We shouldn't change something this fundamental without good cause. -- nosy: +pablogsal, rhettinger

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Change by Eric Snow : -- nosy: +eric.snow nosy_count: 2.0 -> 3.0 pull_requests: +23645 pull_request: https://github.com/python/cpython/pull/24828 ___ Python tracker ___

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

STINNER Victor added the comment: > Actually, interp->none shared _Py_NoneStruct variable. My PR 18301 is a draft to check if we can solve the issue without breaking the C API compatibility. You're right that it doesn't solve the issue, it only checks the C API issue. IMO the PR 18301

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

junyixie added the comment: > Which API should be used in C extensions to be "subinterpreter-safe"? ?> > Currently, Py_None is a singleton shared by multiple interpreters. > > > > Should suddenly all C extensions use a new Py_GetNone() function which > > returns the per-interpreter

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Mark Shannon added the comment: Those numbers are for code without immortal objects. They don't apply in this case, as the branch misprediction rate would rise. -- ___ Python tracker

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Change by STINNER Victor : -- components: +Subinterpreters -Interpreter Core ___ Python tracker ___ ___ Python-bugs-list mailing

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Change by Steve Dower : -- nosy: +steve.dower ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

STINNER Victor added the comment: bpo-40255 proposes a concrete implementation of immortal objects: it modifies Py_INCREF and Py_DECREF which makes Python up to 1.17x slower. -- ___ Python tracker

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

STINNER Victor added the comment: I expect that for objects which are not commonly modified by two interpreters "at the same time", it should be fine. But None, True, small integer singletons, latin-1 str single character singletons, etc. objects are likely to be frequently accessed and so

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Mark Shannon added the comment: Having two CPUs write to the same cache line is a well known performance problem. There's nothing special about CPython here. The proper name for it seems to be "cache line ping-pong", but a search for "false sharing" might be more informative. --

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Larry Hastings added the comment: > The problem with having a single immortal `None`, is that it will > cause data cache thrashing as two different CPUs modify the > refcount on the shared `None` object. That's a very reasonable theory. Personally, I find modern CPU architecture bewildering

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

STINNER Victor added the comment: Mark: > The problem with having a single immortal `None`, is that it will cause data > cache thrashing as two different CPUs modify the refcount on the shared > `None` object. Yeah, I concur with Mark: having one singleton per interpreter should provide

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Mark Shannon added the comment: Consider the case where a thread that doesn't hold the GIL attempts to get a reference on `None`. The problem with having a single immortal `None`, is that it will cause data cache thrashing as two different CPUs modify the refcount on the shared `None`

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Larry Hastings added the comment: > We should do that for each singletons: > > * None (Py_None) > * True (Py_True) > * False (Py_False) > * Ellipsis (Py_Ellipsis) Aren't there a couple more lurking in the interpreter? E.g. empty tuple, empty frozenset. > That is exactly why I didn't

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Change by hai shi : -- nosy: +shihai1991 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Change by Maciej Szulik : -- nosy: +maciej.szulik ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

STINNER Victor added the comment: Ah, I also found the idea of immortal None in an old discussion on tagged pointer: https://mail.python.org/archives/list/capi-...@python.org/thread/JPUNPN3AILGXOA3C2TTSLMOFNSWJE3QX/ Stefan Behnel proposed the idea: "All negative refcounts would have special

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

STINNER Victor added the comment: > (as noted above) make dealloc() for singletons a noop I expect issues with negative reference count value. As you wrote, it triggers a fatal error when Python is built in release mode. > make the initial refcount sufficiently large such that it is

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

STINNER Victor added the comment: > The other approach is to leave the current static singletons alone and > only use them for the main interpreter. Each subinterpreter would get > its own copy, created when that interpreter is initialized. Which API should be used in C extensions to be

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Eric Snow added the comment: > This is pretty much one of the two approaches I have been considering. The other approach is to leave the current static singletons alone and only use them for the main interpreter. Each subinterpreter would get its own copy, created when that interpreter is

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Eric Snow added the comment: On Sun, Feb 2, 2020 at 3:32 PM Raymond Hettinger wrote: > Random idea (not carefully thought-out): Would it be simpler to have these > objects just > ignore their refcount by having dealloc() be a null operation or having it > set the refcount > back to a

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Eric Snow added the comment: On Sun, Feb 2, 2020 at 2:53 PM Raymond Hettinger wrote: > Is the sub-interpreter PEP approved? PEP 554 is not approved yet (and certainly is not guaranteed, though I'm hopeful). However, that PEP is exclusively about exposing subinterpreters in the stdlib.

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Jeremy Kloth added the comment: +1, obviously, as I came to the same conclusion above (see msg361122) -- ___ Python tracker ___

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Raymond Hettinger added the comment: Random idea (not carefully thought-out): Would it be simpler to have these objects just ignore their refcount by having dealloc() be a null operation or having it set the refcount back to a positive number). That would let sub-interpreters share the

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Raymond Hettinger added the comment: Is the sub-interpreter PEP approved? If not, I had thought the plan was to only implement PRs that made clean-ups that would have been necessary anyway. -- nosy: +rhettinger ___ Python tracker

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

STINNER Victor added the comment: Recently, Petr Viktorin proposed immortal singletons in my latest "Pass the Python thread state to internal C functions" thread on python-dev list: https://mail.python.org/archives/list/python-...@python.org/message/RAVSH7HYHTROXSTUR3677WGTCTEO6FYF/ In 2004,

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

STINNER Victor added the comment: I vaguely recall discussions about immortal Python objects. (*) Instagram gc.freeze() * https://docs.python.org/dev/library/gc.html#gc.freeze * https://instagram-engineering.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172 (*) Python

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Jeremy Kloth added the comment: > The problem is to make Py_INCREF/Py_DECREF efficient. That is exactly why I didn't propose a change to them. The singletons still are refcounted as usual, just that their ob_refcnt is ignored. If they somehow reach 0, they just "resurrect" themselves and

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

STINNER Victor added the comment: PR 18301 is a WIP showing my intent. I'm not sure if it would be possible to land such change right now in Python. It has different drawbacks described in my previous messages. I don't know the impact on performance neither. --

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Change by STINNER Victor : -- pull_requests: +17678 pull_request: https://github.com/python/cpython/pull/18301 ___ Python tracker ___

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

STINNER Victor added the comment: New changeset 4d96b4635aeff1b8ad41d41422ce808ce0b971c8 by Victor Stinner in branch 'master': bpo-39511: PyThreadState_Clear() calls on_delete (GH-18296) https://github.com/python/cpython/commit/4d96b4635aeff1b8ad41d41422ce808ce0b971c8 --

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

STINNER Victor added the comment: > Would it not suffice to just make the singletons "immortal"? The problem is to make Py_INCREF/Py_DECREF efficient. Last time someone tried to use an atomic variable for ob_refcnt, it was 20% slower if I recall correctly. If many threads start to update

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

STINNER Victor added the comment: New changeset 7dc140126e918cc7c6e65aea321b7255f0020798 by Victor Stinner in branch 'master': bpo-39511: Fix multiprocessing semlock_acquire() (GH-18298) https://github.com/python/cpython/commit/7dc140126e918cc7c6e65aea321b7255f0020798 --

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Jeremy Kloth added the comment: Would it not suffice to just make the singletons "immortal"? Without affecting the hotpaths that are Py_INCREF and Py_DECREF, changing _Py_Dealloc to test for objects with a "special" destructor could be used: destructor dealloc = Py_TYPE(op)->tp_dealloc;

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Change by STINNER Victor : -- nosy: +eric.snow, nanjekyejoannah, ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Change by STINNER Victor : -- pull_requests: +17673 pull_request: https://github.com/python/cpython/pull/18298 ___ Python tracker ___

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

Change by STINNER Victor : -- keywords: +patch pull_requests: +17671 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18296 ___ Python tracker ___

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

New submission from STINNER Victor : The long-term goal of the PEP 554 is to run two Python interpreters in parallel. To achieve this goal, no object must be shared between two interpreters. See for example my article "Pass the Python thread state explicitly" which gives a longer rationale: