3 ms·
> If no-GIL has a 10% single thread performance hit, that means that essentially all my existing python code would be that much worse. Maybe in a 100% CPU boun
by vb-8448 3y ago
> If no-GIL has a 10% single thread performance hit, that means that essentially all my existing python code would be that much worse.
Maybe in a 100% CPU bound code, most of the code is I/O bound and no one will notice the change, just my opinion.
- burnished 3y agoIt might be more helpful to think of it in terms of supported use cases, rather than just pure volume.
- wongarsu 3y agoMaybe that's just my bubble, but I see much more python in data science projects than in web servers. And in (python) data science even your file reading/writing code quickly gets CPU bound.
- baq 3y agoThere was a time like 5-10 years ago where Python was really popular for grassroots web projects. Nowadays this is mostly node looks like.
- coldtea 3y agoNot in pure Python, that's in specialized libs, like numpy, pandas and co, done in C. So, the hit on the Python interpreter wouldn't translate to a hit on those.
- regularfry 3y agoThat's going to be CPU-bound in numpy's C extensions rather than Python itself, one would hope. The worst of all worlds is that we get a 10% perf cut to python execution and numpy breaks because the C API is ripped up.
- gpderetta 3y agoThat's because you are doing it wrong. You'll need to split every step of your data science pipeline into a microservice, then put it in the cloud for resilience. Then the application will be so fast that it is no longer CPU bound but I/O bound.
- celeritascelery 3y agoMaybe, but if your code is I/O bound, then multi-threading isn't going to help you either.
- School-Cotton 3y agoBut the GIL doesn't need to be held in I/O-bound code anyway, so why does it matter?