Le mer. 13 nov. 2019 à 14:28, Larry Hastings <la...@hastings.org> 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 wrote: "The current means of accessing the thread state does seem rather convoluted, whereas accessing from a thread local is quite efficient (at least with GCC) https://godbolt.org/z/z-vNPN " https://github.com/python/cpython/pull/17052#issuecomment-552538438 Copy of his C code: """ extern __thread int extern_tl; int get_extern_thread_local(void) { return extern_tl; } __thread int tl; int get_thread_local(void) { return tl; } """ And the generated assembly (by godbolt.org service): """ get_extern_thread_local(): mov rax, QWORD PTR extern_tl@gottpoff[rip] mov eax, DWORD PTR fs:[rax] ret get_thread_local(): mov eax, DWORD PTR fs:tl@tpoff ret tl: .zero 4 """ TLS variable read is basically one or two MOV in the Intel x86 assembly (using GCC 9.2). With a friend, I looked at the assembly to read and write atomic variables. In short, only the write requires a memory fence, whereas the read is basically just a MOV (again, in Intel x86). #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. Not why just a regular global variable? By if we change something, I would prefer to move to a TLS variable instead, to support subinterpreters. Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WBCBLDGZ7QBWPOQUIWFNYG7L4UMDIXU5/ Code of Conduct: http://python.org/psf/codeofconduct/
