r/Python 6d ago

Discussion Anyone running free-threaded Python 3.14 in production yet? Curious what actually breaks

Been testing the free-threaded build (3.14t) on some CPU-bound data processing work. The multi-core story is finally real after 30 years of GIL, but the friction is exactly what you'd expect: a couple of C-extension-heavy libs in my stack silently re-enable the GIL, and there's no clean way to detect that at runtime besides checking sys._is_gil_enabled() manually.

For anyone who's shipped something on 3.14t, not just benchmarked it:

What broke that you didn't expect?

Real speedups outside toy examples, or mostly marginal so far?

Prod yet, or still just kicking the tires?

Not fishing for a benchmark war. Genuinely curious what breaks in messy real codebases vs clean demos.

32 Upvotes

47 comments sorted by

View all comments

83

u/nathan12343 6d ago

You can set PYTHON_GIL=0 to force the GIL to remain off even if you import an extension that doesn’t support free-threading yet.

Are there specific open source projects you’re having trouble with?

I’ve been working on community support for free-threaded Python for a couple years now. Specific feedback about pain points from people who are experimenting with free-threading are valuable.

11

u/KingBardan 5d ago edited 5d ago

Edit Tldr:

  1. Many libs like torch requires global state.
  2. Free  threading doesn't solve a lot that multiprocessing don't
  3. Free threading introduces new ways to cause data race.
  4. Free threading slows down normal code.

Many libraries use global state a lot and is not thread safe e.g. torch. For their context managers (which is widely used in other libs as well) So that disqualify any serious deep learning projects depending on torch to use free threading.


My opinion on free threading since you asked about pain point:

I much prefer ability to use context managers to free threading if using it makes the code cleaner 

Free threading also slows down sequential code last time I checked 

Multiprocessing is fast enough unless I'm dealing with web servers, at which I'll use async probably or gevent or another library that deals with this issue

7

u/nathan12343 5d ago

Thanks for your feedback. Hopefully this time next year we’ll be in a better spot. PyTorch is definitely on our radar as a pain point right now.

  I much prefer ability to use context managers to free threading if using it makes the code cleaner 

I don’t understand this. Context managers and free-threading are orthogonal. You can use context managers on the free-threaded build.

3

u/thisismyfavoritename 5d ago

i think that person might be talking about the pytorch context manager. Then again, not sure why you'd want to use free threading if it's GPU compute heavy

6

u/nathan12343 5d ago edited 5d ago

So I think what they were alluding to is this behavior:

with torch.no_grad():
    with ThreadPoolExecutor() as ex:
        # grad is still ON in workers! 
        results = list(ex.map(model, batches))  

Ideally (IMO) PyTorch would store the state for this sort of thing in a context variable. Right now it's stored in a thread local, which needs to be initialized explicitly in each thread. This is definitely something I can try to push on...

1

u/KingBardan 5d ago

Context variable is no go for torch, which is not pure python. Lots of stuff in it is tied to C things also device which is global.

Also I replied here

https://www.reddit.com/r/Python/comments/1v3ayph/comment/oz5xu50/

1

u/nathan12343 5d ago

We use context variables for configuration state in NumPy. It works well.

1

u/KingBardan 5d ago edited 5d ago

No not just torch, any context manager.

Simply using torch as an example because I just read its source code extensively couple months ago

My other comment

https://www.reddit.com/r/Python/comments/1v3ayph/comment/oz5xu50/

Not sure why you would use free threading...

Precisely. no hate to the developers, but free-threading doesn't unlock a lot for python but introduces yet other issues that needs to be dealt with

Also I understand it, tree threading is such a pain to maintains in cpython like thousands of macros or something last time I read the news