Re:No-GIL mode coming for Python
by spamizbad on Friday July 28, 2023 @09:21PM
(#36915754)
This probably isn't going to be that groundbreaking for your average web application. But for several of the niches where Python has a large footprint (AI, Data Science), being able to spin up a pile of cpu/gpu-bound threads and let them rip is a huge boon.
[ Parent
| on HN ]
how likely, the corresponding code doesn't release GIL already? Pure Python is 100x slower than native code therefore the number crunching itself happens in C extensions where GIL can be released.
Re:No-GIL mode coming for Python
by usrbinbash on Saturday July 29, 2023 @03:47AM
(#36917899)
> therefore the number crunching itself happens in C extensions
The number crunching does, but distributing the workload, receiving results, storing and retreiving data, etc. doesn't. And these are huge losses in performance that could be avoided if we could parallelise them.
The moment you need to do something that there's not extension coverage for, or the extension primitive is too small, you're contending the GIL.
It's pretty nice to be able to just throw cores at a problem during prototyping phases, compared to throwing developer time to write native code.
This is a real problem-- which is why there's a whole lot of numpy/scipy maintainers in favor of the change.