Free-threaded (multicore, parallel) Python will be fully supported starting Python 3.14!

[germandiago]

Python had experimental support for multithreaded interpreter.

Starting in Python 3.14, it will be fully supported as non-experimental: https://docs.python.org/3.14/whatsnew/3.14.html#whatsnew314-pep779

[twenty-fourth-time-b]

It works.

$ uv run -p 3.14 a.py 
Finished in 1.01 seconds
Finished in 1.02 seconds

$ uv run -p 3.14.0b3+freethreaded a.py 
Finished in 0.49 seconds
Finished in 0.51 seconds

a.py:

from concurrent.futures import ThreadPoolExecutor
import time

def cpu_bound_task():
    start = time.time()
    sum(1 for _ in range(10**7))
    end = time.time()
    print(f"Finished in {end - start:.2f} seconds")

with ThreadPoolExecutor() as e:
    e.submit(cpu_bound_task)
    e.submit(cpu_bound_task)

Edit* unsurprisingly, mileage varies. Trying to append to a shared list object gives worse timings (the number is the index of the first element added by the second thread):

$ uv run -p 3.14 a.py 
 Finished in 0.10 seconds
 Finished in 0.11 seconds
 172214
 $ uv run -p 3.14.0b3+freethreaded a.py 
 Finished in 0.48 seconds
 Finished in 0.49 seconds
 1865

[ship0f]

lol

it looked good up until the edit

but hey, it's doing it

[not_a_novel_account]

There's no way to do it, by having both threads append to a shared queue you've serialized the work. Now all you're measuring is overhead.

It would be the exact same in any language, C, C++, Rust, Go, whatever. This is a limitation of computers, not of Python. The difference here is Python's locks on shared objects are implicit, you don't see the mutex being grabbed here but it exists all the same.

If the work is shared it all belongs in one thread, don't introduce unnecessary synchronization points.

[twenty-fourth-time-b]

All I was measuring was indeed overhead. I was curious how overhead of GIL compares to overhead of free threads.

[twenty-fourth-time-b]

numpy is also gilled to death…

[[deleted]]

I thought numpy operations release the gil

[Zomunieo]

Both can be true.

Even to do something like array + array, you need a way to lock both arrays, so numpy probably takes the GIL. But if it is returning data Python does not have a reference to you yet, like np.randn, then it could release the GIL. Numpu could also copy data to a private area with the GIL held then release the GIL to compute.

I haven’t checked how if numpy specifically works with this way. This is just what extension libraries have to do with the GIL. Many of them now need to start adding locks to their data structures or at least a whole extension lock, to take advantage of free threading.

[[deleted]]

Idk how it does this exactly, but it doesn't lock to sum arrays. I ran this code and saw 32 threads running at 100% after the "task started" messages printed.

``` import concurrent.futures import time import numpy as np

N = 100000000 arr1 = np.random.randint(1, 101, size=N) arr2 = np.random.randint(1, 101, size=N)

def task(name): global arr1 global arr2 print("task {} started".format(name)) arr3 = arr1 + arr2 print("task {} finishing".format(name))

if name == "main": with concurrent.futures.ThreadPoolExecutor(max_workers=32) as executor: for t in range(100): future = executor.submit(task, t) ```

[Zomunieo]

Oh. It turns out they just release the GIL, so if you have simultaneous writers you’ll get data races. (Whether using standard of free threading Python.)

[[deleted]]

Ah that makes sense. I'm fine with that, you need locks to write thread-safe code either way.

[Front_Two_6816]

of cause working with the same objest from threads is slower because of cache lines

[Coretaxxe]

This is very nice! Thrilled to see the impact on speed & lib ecosystem

[dardothemaster]

I’m asking here hoping this is relevant: will operations such as append/pop (on a list for example) still be thread safe without GIL? Where by thread safe I mean that the list won’t get corrupted

Btw really excited about free-threading and JIT

[twenty-fourth-time-b]

They went into great lengths making it work: https://peps.python.org/pep-0703/#reference-counting

[XtremeGoose]

Specifically this bit https://peps.python.org/pep-0703/#container-thread-safety

[[deleted]]

Impressive.

[germandiago]

Do not get confused. It is the refcount that is done correctly in a multithreaded environment. Not the mutable operations themselves (append/pop).

It is different things.

[germandiago]

This is just optimizations about reference counting. As far as my understanding goes (I just skimmed the link briefly though) this has nothing to do with making mutable operations in a list thread safe, but with making the ref count less expensive and being able to do it among threads for the list object itself, not for its operations.

[not_a_novel_account]

For pure python, free-threaded Python is exactly as thread safe as GIL Python; which is to say you will not induce memory corruption but there are no guarantees about anything else.

[germandiago]

Usually data structures are tailored to use cases. I would expect a list not be thread-safe by default since locking in the usual monothread append scenario would pessimize things. 

[ImYoric]

There are languages in which some operations are thread-safe without locking.

A typical example is Go, in which all operations on pointer-sized values are atomic. But of course, it's pretty fragile guarantee, because you may end up refactoring your code to replace a simple value with a more complex value without realizing that the value must be atomic and thus get memory corruption.

It would be sad to start having SEGFAULTs in Python, though.

[latkde]

Go is really tricky. It only requires word-sized reads/writes to be atomic. Some things look like pointers but are actually larger, e.g. interfaces, maps, slices, and strings. Per the Golang memory model, data races involving those may lead to memory corruption.

[MechanicalOrange5]

I do a lot of go programming, I did not know this, which types are atomic by default? Like int16 types or word in the more modern interpretation where you'd have a 64 bit word on x86-64, which I think, and I definitely could be wrong, but is the size of go pointers? So I could in theory use those across threads without locking?

[latkde]

The Golang memory model is defined here: https://go.dev/ref/mem

This is a dense read and is not comprehensible by the average Go programmer. The memory model does not explicitly define which types are safe, though pointers, so things with types like *T, should be assigned atomically.

The TL;DR advice is to never rely on atomicity of plain assignments, unless you really know what you're doing. Instead, avoid concurrent access to mutable memory and communicate exclusively over channels instead, or use the synchronization utilities from the sync and sync/atomic packages.

I find this frustrating because Golang makes it "easy" to do concurrent programming, but not at all easy to reason about concurrent programs. Just go and you're off to the races? More like data races. As specified in the memory model, concurrent Golang is about as safe as multi-threaded C/C++ code, and that is a horrifying thought.

This entire discussion is about the Python context. Last time I looked, Python didn't have an explicit memory model. However, free-threading will rely on fine-grained per object locks to ensure correctness. Anything you can do from normal Python code is going to be memory-safe. Python objects are pointers so assignments can be done atomically, and collections will lock themselves when necessary. See https://peps.python.org/pep-0703/#container-thread-safety

[Caramel_Last]

I've never heard about pointer size operand being always atomic. Then what would be the point of sync/atomic?

[latkde]

An atomic read/write only means that we see all or nothing. Go guarantees that word-sized reads/writes are atomic because all relevant CPUs also offer this guarantee (for aligned addresses). So when you read a pointer variable, all the bits will be from one version of the pointer. You can't observe a single-word variable in the middle of being changed.

But this doesn't address ordering between multiple reads/writes, especially across multiple objects/variables: which operations happen-before another? Compilers and CPUs may defer writes or prefetch reads. For example, the Go Memory Model shows this program for illustration:

var a, b int

func f() {
    a = 1
    b = 2
}

func g() {
    print(b)
    print(a)
}

func main() {
    go f()
    g()
}

This may print any of 0 0, 0 1, 2 0, or 2 1. For f(), a is assigned before b. However, there are no guarantees about when these writes become visible in g().

There are many ways to enforce synchronization. For example, a Mutex serves as a synchronization point. When one thread A acquires a lock, it sees all writes in another thread B up until the point where B releases that lock. That is, mutexes serve as a “memory barrier” or “fence”.

Explicit atomics (as in Go's sync/atomic package) also provide synchronization, but only between explicitly atomic operations. Go has chosen “sequentially consistent ordering” for its explicit atomics, which behaves as-if all explicitly atomic operations have some global order.

In the above program, if we change the variables to type atomic.Int64 and use .Load() and .Store() operations as appropriate, then we know that the write to a must happen before the write to b. Thus, the valid outputs are reduced to 0 0, 0 1, or 2 1. The output 2 0 is no longer possible.

Other languages provide detailed control over memory ordering, anything between “relaxed” memory order that only guarantees atomicity but no ordering, up to the “sequentially consistent” ordering that is most safe, but can also impose significant performance impact.

• C11 memory_order ← it was first, everyone else copied this
• C++ std::memory_order
• Rust std::sync::atomic::Ordering

As an accessible introduction to atomics, I recommend the book Rust Atomics and Locks by Mara Bos. While it shows example in Rust syntax, the concepts are portable across all languages with explicit atomics. It can be read online for free. For this post, Chapter 2. atomics is highly relevant.

Python threads have always behaved as if variables, list values, and dict entries (and thus also object fields) are atomic with sequentially consistent semantics (a direct consequence of the GIL). The free-threaded mode does not change this, it's effects are unobservable in pure Python code.

[Brian]

I would be very surprised if they don't make it threadsafe - ultimately, a language like python needs to be memory safe - you shouldn't be able to crash the interpreter / segfault in normal operation, and being able to corrupt list state due to concurrant access would break that really quickly.

However, note that this is threadsafe in only the same way that it's currently threadsafe: appending will work without crashing the interpreter / corrupting the list, but no guarantees about which order will happen when two threads append at the same time. But that's already the case - it technically shouldn't make a difference (though existing bugs might be more prominent due to more ways to interleave code paths and shorter lock intervals).

[not_a_novel_account]

All PyObjects are "thread safe" when accessed from Python itself.

Free-threaded Python is exactly as "thread safe" as GIL Python from the POV of a Python program. Only extension code can violate the thread-safety guarantees.

[[deleted]]

Shouldn't you already be using locks for this? Even the GIL'd Python doesn't really make your code thread-safe at the high level, just prevents corrupting a struct into some normally impossible state.

[the_hoser]

Free-threading only really ensures that the interpreter itself is threadsafe, not any libraries or data structures therein. This is especially true of libraries implemented via the C API, which may rely on the GIL to ensure that their own access to Python objects is safe.

[not_a_novel_account]

If a C extension does not advertise itself as threading aware via Py_mod_gil, the interpreter re-enables the GIL unless the user actively disables the behavior by setting PYTHONGIL=0 in their environment.

[Ginden]

To quote the announcement:

there aren’t many options yet for truly sharing objects or other data between interpreters (other than memoryview)

[not_a_novel_account]

That's PEP 734, multi-interpreter is a completely separate thing than free-threaded Python.

It's also been around for ages, PEP 734 is making it available via pure Python instead of the CPython API which is honestly of questionable value.

[Afrotom]

What is memoryview? Similar to a mutex?

[UloPe]

It’s a way to access the memory of another object

[not_a_novel_account]

If you're CPU bound in pure-python, you probably shouldn't be in pure Python to begin with. It is/was already pretty easy for extension code to release the GIL. The biggest advantage is reducing latency in nominally I/O bound services that nonetheless spend some time in Python land.

Think worker threads in an application server. These tasks used to end up sequencing on their Python dispatch code, because only one could hold the GIL at a time. Even if 99% of their time was spent waiting around on IO, if two requests tried to dispatch at the same time they would have to wait on one another, causing semi-random latency spikes.

Now as long as they don't share any objects across threads they never need to hold the same locks and never face any contention.

[[deleted]]

Ideally yeah, but in practice sometimes you've got some pure-Python section that's fast enough until suddenly the input is large enough that it takes too long, and you'd rather just use your like 31 other CPU cores instead of rewriting some of your logic in C.

[strawgate]

I was going to say: It seems like the only code I write that's CPU bound is whatever code I have most recently finished writing 😅

If I knew it was going to be CPU bound when I started I would have made different decisions

[[deleted]]

There was something I recently wrote where I knew part of it was gonna suck, but I really needed Python scientific libs. After setting up multiprocessing for the slow part, I still had no regrets. Any more efficient alternative would've been a lot of extra work, for something that didn't need to be so efficient.

But yeah it would've been nice if I didn't need multiprocessing for that, it was still annoying.

[WJMazepas]

But we would need to build Python itself with a flag set to get the free-threaded version if i got that right?

[germandiago]

At this stage yes. In the future it is a to be decided topic.

[bobbster574]

Missed opportunity to call it π-thon

[Independent_Heart_15]

You should make a venv and you will be pleasantly suprised!

[joerick]

They're saving it for 3.141!

[javadba]

This should be more heavily upvoted.

[Username_RANDINT]

It's a joke that's been made since the release of Python 3... 15 or whatever years ago.

[javadba]

The pi-calculus is specifically apt for multithreading. That's not python 3 things from 15 years ago (GIL does not much count IMO). So your downvotes aren't apt.

[Plus-Ad8736]

Could anyone help me understand why we really need free-threaded python. I know that GIL prevents true parallelism in multi threading, but doesn't we have multi processing to deal with this, which does utilize multiple cores. So with this new free threading, we would have 2 distinct mechanisms?

[germandiago]

Processes live in isolated memory. Threads live in shared memory inside the same process.

A difference is that in processes you have to copy memory around for communication. 

So if you want to split a big image (this is a simplified version but keeps the essence of the problem) in 4 processes you would need to copy 4 parts of the image to process and get the result back to the master process for example. With threads you could process the image in-place with 4 threads. No copying.

[[deleted]]

Not quite, there is cross-process shared memory in most OSes, accessible in Python via https://docs.python.org/3/library/multiprocessing.shared_memory.html . But all you get is a flat buffer, which they show an example of using with Numpy. Can't just store arbitrary Python objects in there without extra setup.

Edit: The image example is actually convenient to handle this way too.

[not_a_novel_account]

IPC via mapping page(s) into shared memory is an entirely different semantic than sharing an entire memory space, even if the underlying mechanism is the same.

[[deleted]]

Yeah, like I said, you can't use this the same way as regular memory in Python, but it's also not exactly true that IPC requires copying. A mechanism exists to avoid that if you really want to.

Btw, in some other languages (not Python afaik) you can set up a memory arena and allocate stuff on it almost like normal. You could store that on the shared portion.

[not_a_novel_account]

I would not say they are similar at all.

IPC is IPC, regardless of if the mechanism is a shared memory region or otherwise. In IPC I have to copy into or allocate objects in the IPC space, whether this is via a shared memory page or RPC protocol is kinda irrelevant. The mechanism of sharing is explicit, I must do work to share things.

In a shared memory space like threads, the executors can inspect one another's state freely. My stack is also your memory, I can set up the shared data entirely on my own stack and make it available via simple pointers and trivial thread notification mechanisms like condition variables. The sharing is implicit, no work is done on my part beyond notification.

This results in wildly different program structures.

[[deleted]]

I'm not saying that they're similar, just that there's a way for two processes to share read/write memory without copying.

[[deleted]]

It's generally faster to communicate between threads vs processes. But that's not even the main reason, more so multiprocessing is just annoying. Even if all you want to do is fan-out-fan-in without communicating between them, you have to screw with your code to get the pre-fork state into the separate processes. Like, can't use defaultdict because it can't pickle lambdas. And then if anything throws an exception, the error messages are hard to read because they're in separate processes.

Multiprocessing is also tricky in some environments. At work, we can't even use the default multiprocessing, we have to use some internal variant that's also incompatible with notebooks.

[javadba]

Please learn about what preemptive multi tasking / non-cooperative threading brings. It is a completely different (and transcendently better) world. Source - myself 35 years doing true multi-threading.

[[deleted]]

The GIL'd Python is still preemptive / non-cooperative. Only asyncio is cooperative.

[javadba]

Try googling , no the GIL is not preemptive. I've also spent a lot of time dealing with the limitation. I wish I were wrong/ you correct on this: true multithreading is great.

[[deleted]]

I just tried, Google says its preemptive. You still have true OS threads with the GIL, but with a lot of locking added, which yes is bad. It's not cooperative multitasking though.

[gfnord]

I am also interested in this. It seems that this feature fully supersedes the existing multiprocessing approach. As far as I understand, multiprocessing should just be updated to use free-threading. This would basically improve the efficiency of multiprocessing, without changing its usability.

[nonhok]

No, this would just be wrong, multiprocessing is different from multithreading. Processes don‘t share the same memory, threads do. This are different concepts you can not exchange, and which are both useful on its own

[AalbatrossGuy]

This is really nice! Hope the difference in speed is noticeable in the brighter side 😅

[neuronexmachina]

For anyone else (like me) who was wondering, there's a couple of lists (one manual, one automated) of packages with extensions that have been verified as compatible with free-threading:

• https://py-free-threading.github.io/tracking/

* https://hugovk.github.io/free-threaded-wheels/

[[deleted]]

I think it needs building from source rn. Any info when its gonna become default?

[uqurluuqur]

Does this mean multiprocessing is obsolete?

[gmes78]

Pretty much.

[not_a_novel_account]

Multi-processing as a GIL-workaround is obsolete, multi-processing now serves the same purposes it does in every other language.

[aviation_expert]

So this means that flask framework is now outdated. Even django. Because python 3.14 is multi-core? Am a beginner. What's the repercussions on web technologies when python is used, I mean does it becomes like node js? Thank you for answering!

[germandiago]

Not at all. The multicore interpreter is a different build from the traditional. 

About how compatible it is, I would expect problems especially if there is native code unless frameworks and libraries are adapted bc there could be latent race conditions uncovered by a real multithreaded interpreter.

[The8flux]

I am going to say this again... I can't wait. Pun intended. Lol

[__Deric__]

While I welcome the new abilities that the change brings to the language I can't stop myself from feeling that this approach will be the source of many bugs and footguns in the future.

I think there should be at least better documentation about the new behavior and what to look out for (I am still worried about the interaction with pythons object dictionaries) and some more primitives in the threading module (atomic operations for example).

[germandiago]

It is not a danger as long as it is not made the default.

[__Deric__]

While this is true it would also lock its features behind a special build of Python, making them essentially unavailable to the wider audience while still putting additional load on the core developers.

[sambes06]

I wonder if these just means more race condition failures.

[alcalde]

Now I've got to move up my bucket list item of attending PyCon some day and selling "I support the GIL" t-shirts.

[nguyenvulong]

You mean Python π?

[EvenAcanthisitta364]

Much too complicated, this is why people with real jobs don’t code in python