3 ms·
It still hits the problems, but it can still be better than single-threaded. That's the point of his comment. People say the GIL is bad so they throw the baby o
by aspaceman 7y ago
It still hits the problems, but it can still be better than single-threaded. That's the point of his comment. People say the GIL is bad so they throw the baby out with the bathwater and no longer use threads, which isn't very well-reasoned.
Been a while since I've used Python, but as far as I remember the GIL only affects Python objects. So if you use Numpy for operations, you can avoid the GIL.
- numbernine 7y agoCan you give an example for your last sentence?
- aspaceman 7y agoHere's a link: https://scipy-cookbook.readthedocs.io/items/ParallelProgramming.html https://scipy-cookbook.readthedocs.io/items/ParallelProgramm... And a quote in italics below. And, more importantly for us, while numpy is doing an array operation, python also releases the GIL. Thus if you tell one thread to do: print "%s %s %s %s and %s" %( ("spam",) *3 + ("eggs",) + ("spam",) ) A = B + C print A During the print operations and the % formatting operation, no other thread can execute. But during the A = B + C, another thread can run - and if you've written your code in a numpy style, much of the calculation will be done in a few array operations like A = B + C. Thus you can actually get a speedup from using multiple threads.
- paulddraper 7y ago> as far as I remember the GIL only affects Python objects. So if you use Numpy for operations, you can avoid the GIL. Correct. Threads cannot help Python-heavy code; they can help I/O-heavy or native-heavy code (assuming native code releases the GIL). Even without multithreading, numpy programming can give amazing speedups. It's the reason why data science Python isn't dead in the water.