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 lik
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 threa
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 motiv
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 motivat
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 i
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 o
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 possi
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 spe
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 function
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
bottle
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()
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
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 ext
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 see
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 measure
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 wro
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.
//ar
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 "g
24 matches
Mail list logo
