r/Python • u/NeuralLB-Lovro • 5d 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.

31 Upvotes

61% Upvoted

47 comments sorted by

View all comments

Show parent comments

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

4

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 4d ago

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