> The GIL is actually a way of keeping Python internally uncomplicated at the price of lost efficiency.
Lost efficiency? Barring significant engineering effort, the GIL is definitely more efficient than more fine-grained locking in a single-threaded situation. Which the Python core team considers of prime importance and the main use-case for Python (whether you agree or not is a different issue): previous tentatives to break-up the GIL lead to performance hits considered unacceptable (~20% across the board I believe).
It also tends to keep Python code less complicated as — much as with Javascript — you can not have two threads of Python code running at the exact same time within a process (this, on the other hand, is a very mixed blessing: it prevents people from learning about the brokenness of thread-based concurrency, and it generally breaks code migrated on a GIL-less implementation such as Jython or IronPython)
If an experimental fine-grained locking variant of CPython scales better for, say, CPU-intensive multi-threaded programs on eight-cores, then the decision to use a GIL instead of fine-grained locking loses efficiency in the case of CPU-intensive multi-threaded programs on eight-cores.
(Edit:) I agree with you on GIL being better for the typical case.
> If an experimental fine-grained locking variant of CPython scales better for, say, CPU-intensive multi-threaded programs on eight-cores, then the decision to use a GIL instead of fine-grained locking loses efficiency in the case of CPU-intensive multi-threaded programs on eight-cores.
True, but as far as I know, so far Python core developers haven't been very interested in switching locking strategy depending on the hardware and workload (to be fair, the GIL is so embedded throughout the interpreter and code utilities the mere act of making this more pluggable would likely generate a higher workload than just ripping out the GIL and building a brand new and more modern interpreter/VM from scratch)
Lost efficiency? Barring significant engineering effort, the GIL is definitely more efficient than more fine-grained locking in a single-threaded situation. Which the Python core team considers of prime importance and the main use-case for Python (whether you agree or not is a different issue): previous tentatives to break-up the GIL lead to performance hits considered unacceptable (~20% across the board I believe).
It also tends to keep Python code less complicated as — much as with Javascript — you can not have two threads of Python code running at the exact same time within a process (this, on the other hand, is a very mixed blessing: it prevents people from learning about the brokenness of thread-based concurrency, and it generally breaks code migrated on a GIL-less implementation such as Jython or IronPython)
reply