On 11/13/19 5:52 AM, Victor Stinner wrote:

Le mer. 13 nov. 2019 à 14:28, Larry Hastings a écrit :

...

I did exactly that in the Gilectomy prototype. Pulling it out of TLS was too slow, What do you mean? Getting tstate from a TLS was a performance bottleneck by itself? Reading a TLS variable seems to be quite efficient.

I'm pretty sure you understand the sentence "Pulling it out of TLS was too slow".  At the time CPython used the POSIX APIs for accessing thread local storage, and I didn't know about and therefore did not try this "__thread" GCC extension.  I do remember trying some other API that was purported to be faster--maybe a GCC library function for faster TLS access?--but I didn't get that to work either before I gave up on it out of frustration. Also, I dimly recall that I moved several things from globals into the ThreadState structure, and probably added one or two of my own.  So nearly every function call was referencing ThreadState at one point or another.  Passing it as a parameter was a definite win over calling the POSIX TLS APIs. I also took the opportunity to pass my "reference count manager" data as a separate parameter, which again was per-thread and again was a major win at the time. //arry/

On 13Nov2019 1954, Larry Hastings wrote:

On 11/13/19 5:52 AM, Victor Stinner wrote:

...

Le mer. 13 nov. 2019 à 14:28, Larry Hastings a écrit :

...

I did exactly that in the Gilectomy prototype. Pulling it out of TLS was too slow, What do you mean? Getting tstate from a TLS was a performance bottleneck by itself? Reading a TLS variable seems to be quite efficient.

I'm pretty sure you understand the sentence "Pulling it out of TLS was too slow".  At the time CPython used the POSIX APIs for accessing thread local storage, and I didn't know about and therefore did not try this "__thread" GCC extension.  I do remember trying some other API that was purported to be faster--maybe a GCC library function for faster TLS access?--but I didn't get that to work either before I gave up on it out of frustration.

Also, I dimly recall that I moved several things from globals into the ThreadState structure, and probably added one or two of my own.  So nearly every function call was referencing ThreadState at one point or another.  Passing it as a parameter was a definite win over calling the POSIX TLS APIs.

Passing it as a parameter is also a huge win for embedders, as it gets very complicated to merge locking/threading models when the host application has its own requirements. Overall, I'm very supportive of passing context through parameters rather than implicitly through TLS. (Though we've got a long way to go before it'll be possible for embedders to not be held hostage by CPython's threading model... one step at a time! :) ) Cheers, Steve

On Thu, Nov 14, 2019, at 07:43, Antoine Pitrou wrote:

On Wed, 13 Nov 2019 14:52:32 +0100 Victor Stinner wrote:

...

#define _PyRuntimeState_GetThreadState(runtime) \ ((PyThreadState*)_Py_atomic_load_relaxed(&(runtime)->gilstate.tstate_current)) #define _PyThreadState_GET() _PyRuntimeState_GetThreadState(&_PyRuntime)

_PyThreadState_GET() uses "_Py_atomic_load_relaxed". I'm not used to C99 atomic conventions. The "memory_order_relaxed" documentation says:

"Relaxed operation: there are no synchronization or ordering constraints imposed on other reads or writes, only this operation's atomicity is guaranteed (see Relaxed ordering below)"

Note: I'm not even sure why Python currently uses an atomic operation.

Is it protected by a lock? If not, you need to use an atomic. Since it's theoretically possible to read the current thread state without the GIL held (though not very useful), then an atomic is required.

It sounds like you are saying PyRuntimeState_GetThreadState has two duties, then: "get this thread's thread state" (from the GIL holder - how do other threads get their own thread state), and "get the GIL-holding thread's thread state (from non-GIL holder thread). The former shouldn't need atomic/overhead locking (unless the thread state can be written from other threads), even if the latter does.

Petr, Eric: sure, my question is only about the internal C functions. I have no plan to change the existing C API. Le mer. 13 nov. 2019 à 14:52, Eric V. Smith a écrit :

The last time we discussed this, there was pushback due to performance concerns. I don't recall if that was actually measured, or just a vague unease.

Maybe I was the one who raised a concern about the atomic variable performance. But I never ran a benchmark on that.

I agree with Petr that not breaking existing APIs is of course critical. A parallel set of APIs is needed. But the existing APIs should become thin wrappers, until Python 5000 (aka never) when they can go away.

There is a project of a new C API for Python: https://github.com/pyhandle/hpy I suggested to add a mandatory "context" parameter since day 1. See the current API draft, it has a "ctx" argument: https://github.com/pyhandle/hpy/blob/3266dc295b0be20b41c99f4f4e944d117b3fc87... Example: "HPy v = HPy_Something(ctx);" Victor -- Night gathers, and now my watch begins. It shall not end until my death.

Le sam. 16 nov. 2019 à 20:55, Neil Schemenauer a écrit :

If you use threadstate often, passing it explicitly (which likely uses a CPU register) could be a win. If you use it rarely, that CPU register would be better utilized for passing function arguments you actually use.

Currently, I would say that it's used "rarely". But. If we want to implement subinterpreters, we have to use way more often. Since each interpreter must have its isolated namespace, I expect that even 1+1 should use tstate to get the 2 "singleton" from its private namespace, rather than using a "global" singleton. Basically, all builtin types and all builtin modules should be modified to have one namespace per interpreter. For C extensions, it's an old project to have a "state" passed to module functions, and so be able to have 2 separated instances of the same C extension, rather than having a single global namespace. Examples: https://www.python.org/dev/peps/pep-0489/ https://www.python.org/dev/peps/pep-0573/ I would like to implement subinterpreters. IMHO the project is feasible and if it works, it would make Python more competitive with other programming languages! IMHO fixing the C API (or write a new one) and subinterpreters are the only two most feasible and most realistic projects to optimize CPython right now. Victor -- Night gathers, and now my watch begins. It shall not end until my death.

On Sun, Nov 17, 2019 at 1:58 PM Nick Coghlan wrote:

On Sat., 16 Nov. 2019, 8:26 am Nathaniel Smith, wrote:

...

As you know, I'm skeptical that PEP 554 will produce benefits that are worth the effort, but let's assume for the moment that it is, and we're all 100% committed to moving all globals into the threadstate. Even given that, the motivation for this change seems a bit unclear to me.

I guess the possible goals are:

- Get rid of the "ambient" threadstate entirely - Make accessing the threadstate faster

- Eventually make it easier for CPython maintainers to know which functions require access to a live thread state, and which are stateless helper functions

So the idea would be that eventually we'd remove all uses of implicit state lookup inside CPython, and add some kind of CI check to make sure that they're never used?

- Eventually make it easier for embedding applications to control which Python code runs in which thread state by moving the thread state activation dance out of the application and into the CPython shared library

That seems like a good goal, but I don't understand how it's related to passing threadstate explicitly as a function argument. If the plan is to move towards passing threadstates both implicitly AND explicitly everywhere, that seems like it would make things more error-prone, not less, because the two states could get out of sync. Could you elaborate? -n -- Nathaniel J. Smith -- https://vorpus.org

On Fri, 15 Nov 2019 14:21:53 -0800 Nathaniel Smith wrote:

As you know, I'm skeptical that PEP 554 will produce benefits that are worth the effort, but let's assume for the moment that it is, and we're all 100% committed to moving all globals into the threadstate. Even given that, the motivation for this change seems a bit unclear to me.

I guess the possible goals are:

- Get rid of the "ambient" threadstate entirely - Make accessing the threadstate faster

For the first goal, I don't think this is possible, or desirable. Obviously if we remove the GIL somehow then at a minimum we'll need to make the global threadstate a thread-local. But I think we'll always have to keep it around as a thread-local, at least, because there are situations where you simply cannot pass in the threadstate as an argument. One example comes up when doing FFI: there are C libraries that take callbacks, and will run them later in some arbitrary thread. When wrapping these in Python, we need a way to bundle up a Python function into a C function that can be called from any thread. So, ctypes and cffi and cython all have ways to do this bundling, and they all start with some delicate dance to figure out whether or not the current thread holds the GIL, acquiring the GIL if not, then checking whether or not this thread has a Python threadstate assigned, creating it if not, etc. This is completely dependent on having the threadstate available in ambient context. If threadstates were always passed as arguments, then it would become impossible to wrap these C libraries.

Most well-designed C libraries let you pass an additional "void*" parameter for user callbacks to be called with. A couple of them don't, unfortunately (OpenSSL perhaps? I don't remember). Regards Antoine.

On Mon, 18 Nov 2019 12:39:00 -0500 Random832 wrote:

On Mon, Nov 18, 2019, at 05:26, Antoine Pitrou wrote:

...

...

For the first goal, I don't think this is possible, or desirable. Obviously if we remove the GIL somehow then at a minimum we'll need to make the global threadstate a thread-local. But I think we'll always have to keep it around as a thread-local, at least, because there are situations where you simply cannot pass in the threadstate as an argument. One example comes up when doing FFI: there are C libraries that take callbacks, and will run them later in some arbitrary thread. When wrapping these in Python, we need a way to bundle up a Python function into a C function that can be called from any thread. So, ctypes and cffi and cython all have ways to do this bundling, and they all start with some delicate dance to figure out whether or not the current thread holds the GIL, acquiring the GIL if not, then checking whether or not this thread has a Python threadstate assigned, creating it if not, etc. This is completely dependent on having the threadstate available in ambient context. If threadstates were always passed as arguments, then it would become impossible to wrap these C libraries.

Most well-designed C libraries let you pass an additional "void*" parameter for user callbacks to be called with. A couple of them don't, unfortunately (OpenSSL perhaps? I don't remember).

I think you've missed the fact that the C library runs the callback on an arbitrary thread. The threadstate associated with the thread that made the original call is therefore *not the one you want*; you want a threadstate associated with the thread the callback is run on.

Ah, right, I had overlooked that mention. This does complicate things a bit. In that case you would want to pass the interpreter state and then use this particular interpreter's mapping of OS thread to threadstate. (assuming that per-interpreter mapping exists, which is another question; but it will have to exist at some point for PEP 554) Regards Antoine.