4 ms·
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 pr
by 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)