3 ms·
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
by spamizbad 3y ago
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.
- d0mine 3y agohow 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.
- usrbinbash 3y ago> 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.
- mlyle 3y agoThe 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.