[Python-Dev] Fixing the GIL (with a BFS scheduler)

[Antoine Pitrou]

On Mon, 17 May 2010 10:11:03 PDT
Bill Janssen <janssen at parc.com> wrote:
> 
> I'd hate to let a fundamental flaw like this go through simply because
> someone somewhere somewhen set a completely synthetic deadline.
[...]
> I've read through that issue (several times), and I have to say that I
> wind up gnashing my teeth each time.  Here's a fix that's rejected
> because it "only" supports NT and POSIX threads.  What percentage of
> Python use cases do those two threading systems cover?  Do we know?

Well, if instead of gnashing your teeth, you had contributed to the
issue, perhaps a patch would have been committed by now (or perhaps
not, but who knows?). If you stay silent, you cannot assume that
someone else will stand up for *your* opinion (and the fact that nobody
did could indicate that not many people care about the issue, actually).

> But right now, *everyone* has to be an expert just to use Python 2.x
> effectively on modern multicore hardware

Python works reasonably well on multicore hardware, especially if you
don't run spinning loops and if you're not on Mac OS X. It may lose *at
most* 10-20% performance compared to a single-core run but that's hardly
the end of the world. And some workloads won't suffer any degradation.

Besides, today's multicore CPUs have far better single-threaded
performance than yesteryear's single-core CPUs, which makes the
performance regression issue more theoretical than practical.
In real life, you have very little risk of witnessing a performance
regression when switching your Python from a single-core to a multicore
machine.

Regards

Antoine.