On Mon., 18 Nov. 2019, 8:19 am Nathaniel Smith, wrote:
>
> > - 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
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
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
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
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
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
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
On AMD64 Linux, the location of the thread local data seems to be
stored in the GS CPU register[1]. It seems likely other platforms
and other operating systems could do something similar. Passing
threadstate as an explicit argument could be either faster or slower
depending on how often you use
On Sat., 16 Nov. 2019, 7:29 am Eric Snow,
wrote:
> On Thu, Nov 14, 2019 at 4:12 AM Victor Stinner
> wrote:
> > Another approach would be to pass a "PyContext*" pointer which
> > contains tstate, but also additional fields. But I chose to state with
> > a direct "PyThreadState* tstate" to avoid
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
On Tue, Nov 12, 2019 at 3:11 PM Victor Stinner wrote:
> Are you ok to modify internal C functions to pass explicitly tstate?
I'm also in favor (strongly)! (no surprises there)
The only concerns I've heard is that on some platforms there is a
measurable overhead once you hit a threshold of a
Victor Stinner schrieb am 12.11.19 um 23:03:
> Are you ok to modify internal C functions to pass explicitly tstate?
FWIW, I started doing the same internally in Cython a while back, because
like others, I also considered it wasteful to look it up all over the
place, often multiple times inside of
On Wed., 13 Nov. 2019, 8:06 am Victor Stinner, wrote:
> Hi,
>
> Are you ok to modify internal C functions to pass explicitly tstate?
>
I'll join the chorus of +1's.
With the work you've already done to clearly separate the public APIs from
the internal ones, it's now much clearer which
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
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
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)
>
>
Le jeu. 14 nov. 2019 à 04:55, Larry Hastings a écrit :
> 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
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
I wouldn't worry too much about the the Singletons in this issue; they could be
solved in any of several ways, all of which would be improvements conceptually
-- if performance and backwards compatibility were resolved.
In theory, the incr/decr pair should be delegated to the memory store, with
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
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.
Mark Shannon
On 11/12/2019 5:03 PM, Victor Stinner wrote:
Hi,
Are you ok to modify internal C functions to pass explicitly tstate?
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.
I've long advocated
On 11/12/19 2:03 PM, Victor Stinner wrote:
Hi,
Are you ok to modify internal C functions to pass explicitly tstate?
I did exactly that in the Gilectomy prototype. Pulling it out of TLS
was too slow, and storing it in a global wouldn't work with multiple
actually-concurrent threads.
On 2019-11-12 23:03, Victor Stinner wrote:
Hi,
Are you ok to modify internal C functions to pass explicitly tstate?
In short, yes, but:
- don't make things slower :)
- don't break the public API or the stable ABI
I'm a fan of explicitly passing state everywhere, rather than keeping it
in
24 matches
Mail list logo
