3 ms·
In GIL Python, you might think you could speed something up by multithreading, but it turns out you can't. The GIL will just run it serially anyways. No-GIL me
by lostdog 3y ago
In GIL Python, you might think you could speed something up by multithreading, but it turns out you can't. The GIL will just run it serially anyways.
No-GIL means it is possible to run things in parallel (without resorting to fancy C extensions).
- miraculixx 3y agoIn theory it's easy. In practice you need to design programs very carefully to leverage multiple threads. The same is true for multiple processes, yet that is much easier to reason about and a lot more likely to get it right.
- uneekname 3y ago> and a lot more likely to get it right I get that it's a hard problem, but it isn't a guessing game. Concurrency has always required one to carefully design their program. We will see how Python implements these new APIs, but I trust it will be approachable to those who want to do it.
- miraculixx 3y agoIt's not about the API. The multithreading API (in any language) is easy: 1. Start a thread 2. Give it work to do (data + code) The problems start when multiple threads work on the same data and compete for the same system resources. Agree, it's not a guessing game. But it is a huge state machine with unobvious hidden states. The cure are locks everywhere, and the magic is to find the least number and places of locks to still make it fast and correct, in any and all situations aka race conditions. It's a much harder problem to reason about than most people realize.