On Tue, Feb 27, 2018 at 12:03 AM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Mon, 26 Feb 2018 22:34:00 +1100, Chris Angelico wrote: >> Removing the GIL from CPython is not about "speeding up" the language or >> the interpreter, but about improving parallelism. > > It is about speeding up threaded code which is CPU-bound. I call that > speeding up the language :-) > > Hypothetically, it could also speed up even unthreaded code.
In its purest sense, no, it cannot speed up unthreaded code. Since many Python programs are single-threaded, this restricts the benefits to those programs which can actually parallelize, but the penalties (mainly overhead) usually apply to all programs. > Some language features could internally launch threads and operate using > implicit parallelism. For instance, map(func, seq) could run in parallel > in separate threads whenever Python knew that func had no side-effects, > say for built-ins. There are also parallel algorithms for bignum > arithmetic. If threads were quick enough, I'm sure we could come up with > many more examples. Hypothetically speaking. These are ways of converting single-threaded code into multi-threaded code, which could then benefit from parallelization, which can reduce wall-time for the process as a whole. > (In practice, the old hope that parallel computing would speed everything > up turned out to be flawed. Relatively few tasks are embarrassingly > parallel, most have sequential bottlenecks, and many are inherently > sequential.) Exactly; and it goes further: many modern programmers do not think in terms of parallelism. Even event-driven code takes a bit of getting your head around. Why are async functions preferred over threads? It's not JUST because today's OSes have thread count limits far below socket limits - if that were the sole justification, we wouldn't have language-level support for async/await - it'd be a niche technique used only in the highest-throughput applications. No, async functions are preferred because they *reduce the points where context switching can occur*, thus making it easier *for the programmer*. If there were a way for the language to automatically run things in parallel, the biggest risk is that the programmer who wrote it can no longer understand it. >>> (If it weren't for the EU government funding it, PyPy would probably be >>> languishing in oblivion. Everyone wants a faster Python so long as they >>> don't have to pay for it, or do the work.) >> >> Hm, I didn't know the EU was funding PyPy. Okay. Cool. > > I don't know if they still receive funding, but I know that PyPy really > only got going in a big way when they got a grant from the EU. I think it > paid for at least one developer to work on it full time for a year. > DuckDuckGo is probably your friend if you care about the details. Meh, I don't care that much about what the EU does or doesn't fund. Was just a mild case of curiosity. I had about as much interest as my savings account accrued last year. I'm glad _someone_ funded PyPy, anyhow. It's a great demonstration of what can be done. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
