4 ms·

In the last few hours, this has been silently added to the post, and I cannot post a reply on that site: Jumping on the internet to say that “they” (specifical

In the last few hours, this has been silently added to the post, and I cannot post a reply on that site: Jumping on the internet to say that “they” (specifically, the people you’re not paying a cent to and who aren’t bothered by the GIL because it only penalises a programming style many of us consider ill advised in the first place) should “just fix it” (despite the serious risk of breaking user code that currently only works due to the coarse grained locking around each bytecode) is also always an option. Generally speaking, such pieces come across as “I have no idea how much engineering effort, now and in the future, is required to make this happen”. Fine, then don't bother. But don't insult us or call foul for our pointing out the downside impact on us of this decision. Your assumption that we are naive rubes who don't know how to code is really, really wrong. I have a very good idea how much engineering effort would be involved in fixing the GIL, and I am well aware that Python has involved many person-millennia of gratis work, and am appreciative of both. However, I still disagree with the Python devs' obviously entrenched position that fixing the GIL isn't worth the effort, and I will continue -- even when shouted down by the likes of you -- to advocate for the GIL's removal or some equivalently good solution. (As I said earlier, I am not opposed to STM solutions, but the current one performs unacceptably without special-purpose hardware.) Why? Because I have a single, selfish interest in this. I depend heavily on Python now, and want the language to be better. I have written many lines of Python 2 code that rely on the threading primitives in the standard library. Perhaps it was foolish of me to expect that the threading model offered by the standard library, modeled on Java's threading primitives, would some day work in the same way as Java threads do in practice. Nonetheless, I am left with a real world problem: my CPU-bound threaded Python code does not scale well to multiple cores. I need the GIL fixed, or to rewrite my Python code, or to migrate to another language that supports the standard model of threading programming that real-world programmers have been using for several decades, and which has built-in support from all major operating systems. Or, sure, wait for STM to be ready for prime time and migrate my thread-based semantics to the new STM-based semantics. The best path right for me right now is migration to Jython or IronPython. But then we are still unsupported orphans, living in the third world of Python 2.X. I guess it comes down to: do you want people to actually use this language to write programs they want to write, or do you want Python to be an advocacy platform for "correct" programming? Python's pragmatism has always appealed to me, so the ivory tower reaction to the practical concerns around the GIL really seem dissonant. (And this is coming from an MIT AI Lab Lisp guy who would rather write everything in Lisp. But Lisp lacks Python's wonderful, high-quality third party libraries and developer-centric pragmatism regarding unit testing, documentation, etc.) I know you are tired of hearing people bitch about the GIL, but, really: people write multithreaded programs. They should work as advertised, using native OS threading primitives and taking advantage of the native OS thread scheduler. Why does Python offer threading primitives if the language is not meant to support, from a practical standpoint, multithreaded programs?

anacrolix 14y ago
Damn straight, good rant. The claim about it being simpler to leave the GIL is true. As Nick mentions, there are 2 reasons why it's desirable to remove the GIL: 1) CPU bound work. Generally breaking up CPU bound stuff needs to be coarse grained anyway. By migrating to process-based parallelism, you potentially incur communication overheads, and library issues. Both of these can (in my opinion) for the most part be worked around. 2) Concurrency. The standard workaround here is to use threads until the context switching overhead destroys your performance, or use one of the growing number of concurrency libraries. Twisted, Tornado, gevent and others for example. The issue here is that it's very difficult to vet code to not block your chosen framework. Horror stories abound where this occurs in some rare case and brings down servers or destroys throughput. Here I think Python critically needs to standardize on something, but drags its feet because it requires breaking compatibility with the C ecosystem in CPython. That in turn makes it pointless to use Python unless it has C-like performance of its own, which it does not. Clearly full threading parallelism is required. To that end, PyPy with STM enhancements is the only thing on the radar that has the potential to do this, may we all look forward to it. Further, GCC and other C compiler should start providing builtin STM support in the next few years, this is another opportunity to replace the GIL without endangering the implementations simplicity.
Flimm 14y ago
"They should work as advertised, using native OS threading primitives and taking advantage of the native OS thread scheduler." Just to be clear, Python does use native OS threading primitives, and it does make use of the native OS thread scheduler. Also, Python does support, from a practical standpoint, multithreaded programs, but only if the program is not CPU-bound. I think you could rewrite that paragraph to make the role of the GIL clearer.
- dmbaggett 14y ago
  Fair enough;the distinction is subtle. Python uses native system threads and of course such threads are scheduled by the OS. But in practice, the GIL allows only one thread to run at a time unless the GIL is subverted via C extensions or similar. I get why this is, given Python's architecture and the legacy of the GIL (which dates to the late 90s, when multicore machines were relatively rare and expensive). But it's still not the case that multiple threads "normally" run in parallel, with the OS ensuring fairness, which is what (I think) most programmers would expect threads to do in a general-purpose threaded language.

anacrolix 14y ago

Damn straight, good rant. The claim about it being simpler to leave the GIL is true. As Nick mentions, there are 2 reasons why it's desirable to remove the GIL: 1) CPU bound work. Generally breaking up CPU bound stuff needs to be coarse grained anyway. By migrating to process-based parallelism, you potentially incur communication overheads, and library issues. Both of these can (in my opinion) for the most part be worked around. 2) Concurrency. The standard workaround here is to use threads until the context switching overhead destroys your performance, or use one of the growing number of concurrency libraries. Twisted, Tornado, gevent and others for example. The issue here is that it's very difficult to vet code to not block your chosen framework. Horror stories abound where this occurs in some rare case and brings down servers or destroys throughput. Here I think Python critically needs to standardize on something, but drags its feet because it requires breaking compatibility with the C ecosystem in CPython. That in turn makes it pointless to use Python unless it has C-like performance of its own, which it does not. Clearly full threading parallelism is required. To that end, PyPy with STM enhancements is the only thing on the radar that has the potential to do this, may we all look forward to it. Further, GCC and other C compiler should start providing builtin STM support in the next few years, this is another opportunity to replace the GIL without endangering the implementations simplicity.

Flimm 14y ago

"They should work as advertised, using native OS threading primitives and taking advantage of the native OS thread scheduler." Just to be clear, Python does use native OS threading primitives, and it does make use of the native OS thread scheduler. Also, Python does support, from a practical standpoint, multithreaded programs, but only if the program is not CPU-bound. I think you could rewrite that paragraph to make the role of the GIL clearer.

dmbaggett 14y ago
Fair enough;the distinction is subtle. Python uses native system threads and of course such threads are scheduled by the OS. But in practice, the GIL allows only one thread to run at a time unless the GIL is subverted via C extensions or similar. I get why this is, given Python's architecture and the legacy of the GIL (which dates to the late 90s, when multicore machines were relatively rare and expensive). But it's still not the case that multiple threads "normally" run in parallel, with the OS ensuring fairness, which is what (I think) most programmers would expect threads to do in a general-purpose threaded language.