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

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