[Python-Dev] Fixing the GIL (with a BFS scheduler)
Antoine Pitrou
solipsis at pitrou.net
Mon May 17 19:39:52 CEST 2010
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.
More information about the Python-Dev
mailing list