(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...
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)
Thanks Dwight.
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
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.