Finally, Python 3.14 lets you disable GIL! It's a big deal because earlier, even if you wrote multi-threaded code, Python could only run one thread at a time, giving no performance benefit. But now, Python can run your multi-threaded code in parallel. And uv fully supports it!

Java 25: Finally officially support AOT, we got performance of C Python 3.14: Finally lets u disable GIL, we got performance of 20 years ago Java

Multithreading in Python actually makes sense now!

As far as I remember, when this was in beta, disabling the GIL made multi-threaded code fast, but it caused single-threaded code to run slow. I'm not sure if that's fixed or will be an issue with this.

Small clarification - Multithreading will now work for CPU-bound tasks as well, I/O-related tasks were already able to handle multithreading.

@grok couldn't you do parallel code in python for a while since most of the ml libs are written in C??

and you can have really fast backends too(albeit experimental)

Python is useful, legit tool for quickly doing one-off scripts that automate mundane shit , are not critical in any way and never leave the house. Out of that role it's just a giant moron magnet. If you see Py MT as a big deal, you are using it wrong.

Multiprocessing, however, has worked since 2.6.

geçen konuştuğumuz muhabbet, vay anasını. @mertcobanov

What’s fascinating here is not just the technical leap, but the potential for redefining how Python is used in performance-critical environments. For years, Python has been seen as the “easy” language that trades speed for simplicity. With GIL out of the picture, that narrative starts to change. The question is whether this opens the door to broader adoption in areas traditionally dominated by C++ and Java.

How does its performance compare with other languages like .NET and Java, which already provide this?

This is indeed a significant milestone for Python! The removal of the Global Interpreter Lock (GIL) option in 3.14 addresses one of Python's long-standing limitations for CPU-bound tasks.

If you want performance, it doesn't make sense to choose Python.

No performance benefit for CPU-bound tasks; for IO-bound ones (like making a lot of requests concurrently) threads already provided a lot of performance benefits.

wasnt this available in 3.13 a year ago?

LOL - could do that in C in 1990s 😂🤣

Python is for asynchronous programming. Removing the GIL requires extra synchronization. Net effect: single-threaded code can be noticeably slower vs. regular CPython.

@0sumTX

This is objectively false. Asyncio/ThreadPool can be used to achieve concurrency for I/O tasks and parallelism can be achieved for CPU bound tasks via multi-processing. For I/O tasks (file read, network requests) they can be easily made concurrent via asyncio/ThreadPool where as soon as the task is blocked on the event loop, it will run the next task. Even tho the GIL blocks multiple threads from executing at the same time, whenever there's a blocking task in a thread the GIL is unfrozen and moves to the next thread achieving strong concurrency and near parallelism at small to medium scale. This is how I can scrape 10k+ websites in one seconds ;) For CPU bound tasks (math, which is what i suspect the video is doing), you can use ProcessPool to achieve true parallelism by running each task on a different process, where each task uses separate memory with it's own GIL. i suggest you to read:

Free threading is not a silver bullet; shared state still bites. Split work so threads touch separate data; pass messages, not shared dicts. Pro tip: watch for the t ABI tag; cp314t wheels target free threaded Python, and uv can fetch them. Also, single thread runs may slow a bit; measure, then choose threads or processes.

Python is slow af. It should only be used for scripts not serious code. You’ll have a 100000x speed boost and energy efficiency boost with native code written in c or rust

🤣🤣🤣

I ran the same multi-threaded code I wrote 3 years ago, it ran perfectly well. Same code I had to change three years ago because it wasn’t performing as well as needed.

multi threaded but not multi processing

You could disable gil in 3.13

Woot! Welcome to 1968 🎉

It's just as slow though, it's merely parallel.

Is it faster than spring boot with virtual threads Java 21?

1. Its not enabled by default - you have to choose a custom install. 2. Most packages do not support it yet.

To know about what other things are in 3.14, please read my article

finally! ~ took 30y

Interesting. Thank you!

I deeply tested it last November 2024, and recently again still not completely competing in real-time massive rendering, but it is a good move

phyton lives in the 60s or what?