3 ms·
Honestly, not sure why people care so much about the GIL in languages like Ruby, Python or JS. Let's face it, nowadays when you deploy software it's over multi
by Mikeb85 5y ago
Honestly, not sure why people care so much about the GIL in languages like Ruby, Python or JS.
Let's face it, nowadays when you deploy software it's over multiple machines, nodes, whatever you want to call it. So you're almost always talking about spawning processes. Which any language can do, GIL or not. Removing the GIL to enable parallel processing on a single machine adds more complications than it's worth, especially when any Python workload is either going to be forking C processes or forking Python processes.
Not every language needs the same kind of control over OS threads of a C, C++ or Rust.
- zamadatix 5y agoPeople don't care as much about removing the GIL in JS because JS never exposed threads. When the time came for spreading compute load to multiple cores JS decided to simply create multiple contexts first with just message passing and then later with shared memory. As a result you can still code JS in the typical thread unaware way but utilize multiple cores without having to go multi-process or multi-machine. For in thread stuff the async model (or historically callbacks) is good enough if you're not compute bound. In Python threads are exposed but only one runs at a time and you have to go full multiprocessing to use the other cores. This is both confusing and annoying respectively hence the increased noise about the GIL.
- cma 5y agoWe already have 64 core/128 thread prosumer machines and it is only going to be more in the future. Python is so slow that message passing between processes can often be slower than just handling it in the same process. What if you have a big array of python objects that you want to sort? In other languages it is trivial to get a huge speedup with more cores.