(Posted for the whole Steering Council.) As we’ve announced before, the Steering Council has decided to accept PEP 703 (Making the Global Interpreter Lock Optional in CPython) . We want to make it clear why, and under what expectations we’re doing so. It is clear to the Steering Council that theoretically, a no-GIL (or free-threaded) Python would be of great benefit, and the majority of the community seems in agreement. Threads have significant downsides and caveats, but they are widely adopte...
If this can be achieved, Python’s world domination will be well underway.
Python is already No. 1 in the TIOBE Index, and mutithreading is currently one of Python’s weakest points. I know I’ve decided not to use Python for a personal project a few times because multithreading was important, and I can’t be the only one.
For me personally, whilst I’ll be very glad to see landmine-free multithreading, I don’t want world domination. Other languages exist for good reasons, and trying to adapt Python to fit into other languages shoes isn’t necessarily going to make it better.
What’s wrong with Python’s multithreading? I’ve seen some other accounts that it’s not its strong suit. Is it because it leverages operating system level abstractions to make it happen or something else?
It’s because, in Python, you don’t actually get a parallel speed up when working with threads in CPU heavy tasks, even for embarrassingly parallel problems. This is because CPython implements some concurrency safety for primitive objects by using a global lock for all threads that ensures that only one of them has the interpreter at a time (meaning only one thread runs at a time).
From the CPython built-in threading library documentation:
Until 3.13 we won’t have any built-in way of using multiple cores to speed up CPU bound tasks with just python code, short of creating new processes. Sub-interpretters in 3.12 can now have their own GIL, but that won’t have a python interface until 3.13 releases.
Because of the GIL. Multithreading in python does not work as people would expect from other languages, it can’t do computation in parallel
Interesting, so this means that it could be used for high performance computing if the GIL became optional?
Pure python will likely never be used for that, but python already is used in HPC mostly as a DSL over native code.
There’s really no reason why you couldn’t write a bunch of python that produces a lazy compute graph that can be compiled or optimized under the hood for HPC right now.
The removal of the GIL just makes some stuff a lot easier to parallelize at the python level. Multiprocessing can have a lot of overhead and this would be a nice way to scale up a little.
Actually, it’s even worse than that. The GIL protects prevents you from trashing your interpreter, but you still have to synchronize your Python code or else you get race conditions.
False. As for now, you can just use multiprocessing instead of multi threading to achieve parallel computation (with a little of overhead though)
They said multithreading can’t do parallel computing, what part of that is false?
Besides, going to multiprocessing isn’t just “a little overhead” you need to switch from a shared data model to inter process communication, which isn’t always trivial
There is a common dev story in python: Hrmm this is running slow, maybie I can use threads to make it go faster. Weird, not faster, discovers GIL. Maybe I can use multiprocessing. Hrmm this sucks I have to use IPC and serialize things to pass them. Hrmm faster but still weirdly slow. Proceeds to spend a ton of time optimizing IPC and figuring how to get code in multiple processes to communicate.
You just summarized a week of wasted efforts at my job.
I’ve never heard this story.
GIL removal solves the relatively small problem of, “I have a big workload but not so big that I need multiple nodes.”
Small workloads are fine and don’t need free threading. Large workloads are going to use IPC anyway to coordinate across hundreds of nodes.
Today you must use the IPC overhead approach for medium workloads and it is some extra work. But then if your application grows you’ve already done much of the scaling part.
I misread the previous comment: i read “python can’t do computation in parallel”. Editing
Thanks Dwight.
A little overhead? Each interpreter spawned adds 50mb.of RAM used. Doesn’t sound like much, but on an 8 core, 16 thread CPU, spawning 15 additional interpreters, eats up nearly a gig of ram on its own. On Windows (unsure about Linux/Mac), it also adds time to startup, and you get way less computational power out of it than using something else. Idk if anyone else does this, but I start the processes on program startup so they’re always available.
It’s likely the end consumer doesn’t know/doesn’t care about the slight performance gains, especially when competitors in my niche get away with crap like “your search is in queue, we’ll email you when you’re done”, but I find that abhorrent and lazy and all around stupid, so I take all performance advantages I can get.
You know I’m using tensorflow and it seems to do a great job utilizing all my available cores. I know there’s underlying C code that makes that possible, but I don’t see why that’s a problem. This isn’t a weak point in python. World class C integration is one of the best things about python.
BECAUSE, as you’ve discovered, the part that does the actual calculations in parallel is indeed written in C/C++/CUDA. You are just using python as basically a glorified bash at that point (which is great, because that’s EXACTLY what it was designed for). Python is the PERFECT tool for that job.
There are people out there who want are not satisfied with that. They want to write THOSE performant bits (or ones like it) in pure python. Not with some compilable subset of the language or jit compiler, but with ACTUAL, interpreted, python code. There are people who want to write non-io-limited multi-threaded algorithms IN python. They all believe they are hamstrung by the GIL, and instead of just picking a (compiled w/ proper threading) language much better-suited for that particular job, they are perpetually trying to fit a round peg into a square hole.