GIL removal and the Faster CPython project

Posted Aug 3, 2023 7:57 UTC (Thu) by roc (subscriber, #30627)
Parent article: GIL removal and the Faster CPython project

Seems to me that free-threading is a path to subtle data-race bugs in user code *and* severely limited single-thread performance :-(. I can't think of any similar language interpreter that supports free-threading like this.

It would be helpful if the motivation section for PEP 703 carefully explained why in each case PEP 684 with one interpreter per thread would not mitigate the issue, or could not be enhanced to mitigate the issue. There would still be inter-interpreter communication overhead, but that seems like a much easier problem to solve than PEP 703. E.g. maybe you could build an object migration API that exposes a inter-interpreter object queue, where pushing an object into the queue consumes the object reference. If the object refcount is 1 you can scan the object subgraph, and if any inner objects have refcounts > 1 you copy them or immortalize them, then hand off ownership of the entire object graph to the destination interpreter.

GIL removal and the Faster CPython project

Posted Aug 3, 2023 9:07 UTC (Thu) by mb (subscriber, #50428) [Link] (2 responses)

>I can't think of any similar language interpreter that supports free-threading like this.

There already are Python interpreters without a GIL, like Jython and pypy-stm.

GIL removal and the Faster CPython project

Posted Aug 3, 2023 9:35 UTC (Thu) by roc (subscriber, #30627) [Link] (1 responses)

Thanks, good to know.

They're not exactly mainstream though.

GIL removal and the Faster CPython project

Posted Aug 18, 2023 12:54 UTC (Fri) by sammythesnake (guest, #17693) [Link]

"Not exactly mainstream" is a little generous, to be honest, Jython hasn't yet got support for Python 3 and pypy-stm was abandoned as essentially unworkable several years back...

It's a shame, though - STM in particular was a pretty cool *concept*, even if making it work kinda wants hypothetical hardware support :-P

GIL removal and the Faster CPython project

Posted Aug 3, 2023 9:39 UTC (Thu) by roc (subscriber, #30627) [Link]

To be clear I have no idea how an optimal same-address-space object-transfer protocol would be implemented in Python, but definitely something can be done that's much more efficient than regular IPC. In the JS world there is "structured clone", which supports transferring data buffers to the cloned object without copying.

GIL removal and the Faster CPython project

Posted Aug 3, 2023 21:18 UTC (Thu) by bluss (guest, #47454) [Link] (1 responses)

Interpreter or not, I'm not sure if that matters. C# comes to mind. It makes it easy to spawn new threads, it's a "safe" language, and it's very easy to modify hashmaps from multiple threads at once. And the result is both one's own state as well as the internal state of the collection can be corrupted.

GIL removal and the Faster CPython project

Posted Aug 4, 2023 9:01 UTC (Fri) by zorro (subscriber, #45643) [Link]

In my example above, I was also thinking about C#. I love being able to convert my for/foreach loops into Parellel.For/ForEach with just a few lines of code and get an instant N x speedup. Of course, you need to ensure that the data you are feeding into your parallel loop is "embarrassingly partitionable", but this is true for many workloads.

I'm sure there is some task and thread management overhead under the hood when using this .NET feature, but it does not sound as heavyweight as a Python sub-interpreter (I could be wrong about that)

GIL removal and the Faster CPython project

Posted Aug 5, 2023 9:06 UTC (Sat) by ssmith32 (subscriber, #72404) [Link] (1 responses)

My takeaway from the article was that the whole point of the discussion that was had was to:

- ensure existing python code works the same

- ensure Faster Python (single thread performance) isn't impacted long term. Most notably, by the time no-gil is the default.

So.. you shouldn't see single thread performance go down, and you'll only get into race-condition territory if you actively decide to change how you write your python code.

GIL removal and the Faster CPython project

Posted Aug 8, 2023 18:12 UTC (Tue) by roc (subscriber, #30627) [Link]

Sure, people want to "ensure Faster Python (single thread performance) isn't impacted long term" but that isn't really possible.

You could make the entire JIT state per-thread, I suppose, though that will be slow since you'll have an extra layer of indirection to get to your PICs etc. Otherwise you'll be synchronizing on it some way or another.

You'll definitely have unavoidable overheads making sure that Python object state (e.g. refcounts) isn't corrupted by data races. Sure, do deferred refcounting etc, but you need extra machinery that at some point you'll have to pay for. Also the complexity of the Python implementation is going to soar.