On Thu, Oct 11, 2018 at 6:12 PM Ben Finney <ben+pyt...@benfinney.id.au> 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?
Multi-core machines are important, but even on multi-core machines, most Python processes don't need more than one. AFAIK, every single alternative to the GIL has resulted in a measurable performance penalty when running on a single core. (Happy to be proven wrong if that's not the case.) So if you want better multi-core performance, you MUST accept a single-core penalty. Frankly, I don't see a problem with saying "Python doesn't make it easy to write code that floods eight cores with work, therefore I will choose a different language for this job". It doesn't mean Python is a bad language. It just means that Python is not the one and only language that all code must forever be written in. There's a huge difference between deciding on using some different language for a project, and going on a massive ire-filled rant. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
