[ngoldbaum]

Right now there is a significant single-threaded performance cost. Somewhere from 30-50%. Part of what my colleague Ken Jin and others are working on is getting back some of that lost performance by applying some optimizations. Expect single-threaded performance to improve for Python 3.14 next year.

[arp242]

To be honest, that seems a lot. Even today a lot of code is single-threaded, and this performance hit will also affect a lot of code running in parallel today.

There have been patches to remove the GIL going back to the 90s and Python 1.5 or thereabouts. But the performance impact has always been the show-stopper.

[ngoldbaum]

It’s an experimental release in 3.13. Another example: objects that will have deffered reference counts in 3.14 are made immortal in 3.13 to avoid scaling issues from reference count thrashing. This wasn’t originally the plan but deferred reference counting didn’t land in time for 3.13. It will be several years before free-threading becomes the default, at that point there will no longer be any single-threaded performance drop. Of course that assumes everything shakes out as planned, we’ll see.

This post is a call to ask people to “kick the tires”, experiment, and report issues they run into, not announcing that all work is done.

[andmkl]

That would be in the order of previous GIL-removal projects, which were abandoned for that reason.

[imtringued]

That kind of negates the whole purpose of multi threading. An application running on two cores might end up slower, not faster. We know that the python developers are kind of incompetent when it comes to performance, but the numbers you are quoting are so bad they probably aren't correct in the first place.

[ngoldbaum]

Clarifying a few days later: single-threaded performance in the normal ABI with the GIL does not have the same performance degradation. You only see the performance hit if you’re testing the experimental 3.13 free-threaded release.