On 11/10/2018 09:11, Ben Finney wrote:
Chris Angelico <ros...@gmail.com> writes:
In actual fact, it's not a problem per-se. It's a design choice, and
every alternative choice tried so far has even worse problems. THAT is
why we still have it.
That reads to me like a rejection of the point made in the blog post:
that the GIL prevents Python from taking proper advantage of multi-core
machines.
In other words: Yes, it's a design decision, but that design decision
causes the problems described.
Is it your position that the described behaviour is not a problem? Do
you hold that position because you think multi-core machines are not a
sector that Python needs to be good at? Or that the described behaviour
doesn't occur? Or something else?
I recently watched this talk by Raymond Hettinger on concurrency which
gives some perspective on this question especially in the first ten
minutes: https://www.youtube.com/watch?v=9zinZmE3Ogk
The gist is that the GIL is a problem only for relatively few problems
(e.g. games that need limited-scale low-latency parallelism). Most of
the time, you either only need one process in the first place, or you
can take full advantage of your multi-core machine, or multiple
multi-core machines, using multiple processes (with ipyparallel or whatever)
--
https://mail.python.org/mailman/listinfo/python-list
