4 ms·

The GIL is actually a way of keeping Python internally uncomplicated at the price of lost efficiency. String formatting: that's a case of the "explicit is bett

by limmeau 16y ago

The GIL is actually a way of keeping Python internally uncomplicated at the price of lost efficiency. String formatting: that's a case of the "explicit is better than implicit" dogma. As for "complicated": I'd rather explain to a newbie that % takes a string template and data and substitutes, than that string literals are actually complex expressions with possibly side-effect-ful subexpressions. Versioning problems in language distributions vs Linux distributions: is there a language community without?

masklinn 16y ago
> 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)
- limmeau 16y ago
  Splitting the same hair from the other side: 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.
  - masklinn 16y ago
    > 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)

by limmeau 16y ago

masklinn 16y ago

> 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)

limmeau 16y ago
Splitting the same hair from the other side: 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.
- masklinn 16y ago
  > 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)