GIL removal and the Faster CPython project

Posted Aug 5, 2023 9:06 UTC (Sat) by ssmith32 (subscriber, #72404)
In reply to: GIL removal and the Faster CPython project by roc
Parent article: GIL removal and the Faster CPython project

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.