Store current interpreter as a thread local variable

[kumaraditya303]

There's a lot of code which accesses the current interpreter state especially under free-threading via PyInterpreterState_Get. Currently to lookup interpreter state first the thread state is accessed then read by ts->interp but it can be optimized to be stored in a thread local variable _Py_tss_current_interp so that it can be read directly.

Linked PRs

• gh-140544: cleanup HAVE_THREAD_LOCAL checks in pystate.c #140547
• gh-140544: store pointer to interpreter state as a thread local for fast access #140573
• gh-140544: use faster _PyInterpreterState_GET for type lock #140584
• gh-140544: fix build for including pycore_pystate.h when HAVE_THREAD_LOCAL is not defined #140623
• gh-140544: Always assume that thread locals are available #140690

[corona10]

Do you mean declaring current_interp with _Py_thread_local?
I think it would be worth running a benchmark to see the effect.

[ZeroIntensity]

The (attached) thread state is a thread-local variable; how would adding another one make things any faster?

[kumaraditya303]

I am planning to add _Py_tss_current_interp to store the pointer to current interpreter state so that calls like PyInterpreterState_Get are just a fixed offset tls lookup similar to _PyThreadState_GET.

[ZeroIntensity]

You'd probably be interested in #132312. Thread-local accesses are slow.

[kumaraditya303]

You'd probably be interested in #132312. Thread-local accesses are slow.

Thread-local accesses are slow but what we have currently is even slower because currently first the thread state is read which is thread local then ts->interp which is dependent memory read, by using a dedicated thread local we avoid the dependent memory read.

[ZeroIntensity]

Do you have benchmarks? You have to take into account that we're going to have to read and write to _Py_tss_current_interp any time we attach or detach a thread state, otherwise we break subinterpreters. I'd expect a single pointer read to be pretty fast compared to extra thread-local reads and writes.

[kumaraditya303]

I haven't benchmarked it yet, will do. Attaching and detaching is done primarily before blocking calls which takes much more time so I don't expect the extra tls writes to have meaningful effect.

[kumaraditya303]

Benchmark shows that it is 1% faster on pyperformance with regex upto 9% faster on linux and 3% faster on macos arm64.

[ZeroIntensity]

Surprising!

Do those benchmarks include any code using subinterpreters? I'm mostly concerned about when we're frequently changing the current interpreter.

[kumaraditya303]

Do those benchmarks include any code using subinterpreters? I'm mostly concerned about when we're frequently changing the current interpreter.

Not that I know of, fwiw there's far more overhead in switching interpreters than a single tls write would have any effect, it is literally two mov instructions.