5 ms·

Here's what's puzzling me about this: Why then is there even a need for a seperate nogil build? If it is like this says, wouldn't it be easier to just make the

Here's what's puzzling me about this: Why then is there even a need for a seperate nogil build? If it is like this says, wouldn't it be easier to just make the standard build switch to gil or nogil automatically (or honor the users choice). The fact that the SC thinks having two versions suggests there is more complexity involved than this section of the PEP leads readers to believe.

lozenge 3y ago
You have to recompile your C extensions for the nogil build. Consider an application where one thread is calling xs.append from a C extension and another is calling xs.pop and xs[-1] on the same list object xs. In the nogil build these operations need to use a fine-grained lock on xs, and in the gil build these are thread-safe due to each thread holding the GIL when it does these operations. On top of that, some of the list and dictionary operations are available to extensions as C macros to avoid the overhead of a C function call. However, it looks like the nogil build will be able to run in "GIL mode" for maximum compatibility, including switching to GIL mode partway through execution, but I'm expecting this to be slower than running the gil build in GIL mode.
- Dylan16807 3y ago
  > However, it looks like the nogil build will be able to run in "GIL mode" for maximum compatibility, including switching to GIL mode partway through execution Yes, that's what they were asking about. Why have two versions for a mode switch. Everything you explained before that is irrelevant, I'm afraid. > but I'm expecting this to be slower than running the gil build in GIL mode. That could be the answer to their question, but that's not definitive enough.
  - lozenge 3y ago
    1. The "stable ABI" is broken on nogil, the selling point of the stable ABI was "add this C preprocessor flag and your extension will work on all future CPython versions, after paying a speed penalty". This is useful for eg closed source extensions. If the nogil build was the only build available, these extensions would require recompilation. 2. There are a lot of users that want fast Python and a lot of effort was put in to optimise it. I think the core team wouldn't want to release and expect everybody to use a version which regresses in performance, for a feature (nogil) which most won't be able to use due to using C extensions which haven't had nogil-supporting code changes.
    - Dylan16807 3y ago
      > The "stable ABI" is broken on nogil, the selling point of the stable ABI was "add this C preprocessor flag and your extension will work on all future CPython versions, after paying a speed penalty". This is useful for eg closed source extensions. If the nogil build was the only build available, these extensions would require recompilation. It looks for a flag, if it doesn't see it then it turns the GIL on. Where is the need for recompilation? > I think the core team wouldn't want to release and expect everybody to use a version which regresses in performance But you're just guessing that it's slower in GIL mode, aren't you?
      - lozenge 3y ago
        "Where is the need for recompilation?" https://docs.python.org/3/c-api/typeobj.html#c.PyObject.ob_refcnt https://docs.python.org/3/c-api/typeobj.html#c.PyObject.ob_r... The stable ABI lets extensions access the reference count of any object directly. I don't know why. Normally the functions Py_IncRef and Py_DecRef should be sufficient. Objects no longer have a single number as their reference count. Edit: In Python 3.2-3.9, the stable ABI included Py_INCREF, the C macro. https://docs.python.org/3/c-api/type.html#c.PyType_FromModuleAndSpec https://docs.python.org/3/c-api/type.html#c.PyType_FromModul... The stable ABI lets extensions create new Python types. These can override tp_alloc field to use custom memory allocators when instances of the type are instantiated. The custom memory allocator needs to initialise the reference count to 1. > But you're just guessing that it's slower in GIL mode, aren't you? There are new implementations with per-object locks of list.append, dict.__setitem__ etc. These are incredibly common operations in Python code. These inherently will be more complicated than the previous implementation, meaning more instructions and slower. So there needs to be a branch at the start of list.append of whether to go to the old gil implementation or the new nogil one. Adding a branch so frequently will inherently make the runtime slower. Now with a lot of work these can be optimised and the speed penalty reduced, but CPython goes on an annual release cycle. If the nogil code is held as a fork of the CPython repository without being merged in, until it reaches a performance goal, that brings other issues.
        Dylan16807 3y ago
BiteCode_dev 3y ago
Because it's being prudent. With such a big project, the unknown unknowns are numerous. Something nobody though about lurks in this nogil build, and we are only going to find out when it goes to prod and users report about it. Instead of breaking the entire Python community's code, the risk is opt-in for a few years.

lozenge 3y ago

You have to recompile your C extensions for the nogil build. Consider an application where one thread is calling xs.append from a C extension and another is calling xs.pop and xs[-1] on the same list object xs. In the nogil build these operations need to use a fine-grained lock on xs, and in the gil build these are thread-safe due to each thread holding the GIL when it does these operations. On top of that, some of the list and dictionary operations are available to extensions as C macros to avoid the overhead of a C function call. However, it looks like the nogil build will be able to run in "GIL mode" for maximum compatibility, including switching to GIL mode partway through execution, but I'm expecting this to be slower than running the gil build in GIL mode.

Dylan16807 3y ago
> However, it looks like the nogil build will be able to run in "GIL mode" for maximum compatibility, including switching to GIL mode partway through execution Yes, that's what they were asking about. Why have two versions for a mode switch. Everything you explained before that is irrelevant, I'm afraid. > but I'm expecting this to be slower than running the gil build in GIL mode. That could be the answer to their question, but that's not definitive enough.
- lozenge 3y ago
  1. The "stable ABI" is broken on nogil, the selling point of the stable ABI was "add this C preprocessor flag and your extension will work on all future CPython versions, after paying a speed penalty". This is useful for eg closed source extensions. If the nogil build was the only build available, these extensions would require recompilation. 2. There are a lot of users that want fast Python and a lot of effort was put in to optimise it. I think the core team wouldn't want to release and expect everybody to use a version which regresses in performance, for a feature (nogil) which most won't be able to use due to using C extensions which haven't had nogil-supporting code changes.
  - Dylan16807 3y ago
    > The "stable ABI" is broken on nogil, the selling point of the stable ABI was "add this C preprocessor flag and your extension will work on all future CPython versions, after paying a speed penalty". This is useful for eg closed source extensions. If the nogil build was the only build available, these extensions would require recompilation. It looks for a flag, if it doesn't see it then it turns the GIL on. Where is the need for recompilation? > I think the core team wouldn't want to release and expect everybody to use a version which regresses in performance But you're just guessing that it's slower in GIL mode, aren't you?
    - lozenge 3y ago
      "Where is the need for recompilation?" https://docs.python.org/3/c-api/typeobj.html#c.PyObject.ob_refcnt https://docs.python.org/3/c-api/typeobj.html#c.PyObject.ob_r... The stable ABI lets extensions access the reference count of any object directly. I don't know why. Normally the functions Py_IncRef and Py_DecRef should be sufficient. Objects no longer have a single number as their reference count. Edit: In Python 3.2-3.9, the stable ABI included Py_INCREF, the C macro. https://docs.python.org/3/c-api/type.html#c.PyType_FromModuleAndSpec https://docs.python.org/3/c-api/type.html#c.PyType_FromModul... The stable ABI lets extensions create new Python types. These can override tp_alloc field to use custom memory allocators when instances of the type are instantiated. The custom memory allocator needs to initialise the reference count to 1. > But you're just guessing that it's slower in GIL mode, aren't you? There are new implementations with per-object locks of list.append, dict.__setitem__ etc. These are incredibly common operations in Python code. These inherently will be more complicated than the previous implementation, meaning more instructions and slower. So there needs to be a branch at the start of list.append of whether to go to the old gil implementation or the new nogil one. Adding a branch so frequently will inherently make the runtime slower. Now with a lot of work these can be optimised and the speed penalty reduced, but CPython goes on an annual release cycle. If the nogil code is held as a fork of the CPython repository without being merged in, until it reaches a performance goal, that brings other issues.
      - Dylan16807 3y ago

BiteCode_dev 3y ago

Because it's being prudent. With such a big project, the unknown unknowns are numerous. Something nobody though about lurks in this nogil build, and we are only going to find out when it goes to prod and users report about it. Instead of breaking the entire Python community's code, the risk is opt-in for a few years.