Le Wed, 14 Oct 2009 22:39:14 -0700, John Nagle a écrit : > > Note that multithreaded compute-bound Python programs really suck > on multiprocessors. Adding a second CPU makes the program go slower, > due to a lame mechanism for resolving conflicts over the global > interpreter lock.
I'm not sure what you're talking about. Python has no "mechanism for resolving conflicts over the global interpreter lock" (let alone a lame one :-)), it just trusts the OS to schedule a thread only when it is not waiting on an unavailable resource (a lock). The GIL is just an OS-level synchronization primitive and its behaviour (fairness, performance) will depend on the behaviour of the underlying OS. If this belief is derived from Dave Beazley's slides (*) about Python's multi-threading issues, I'd say some of his observations are rather questionable. First because the measurements were done on OS X, which has its own serious concurrency problems (**). Second because one of the benchmarks is so synthetic that it doesn't reflect real-world use of Python at all. This is not to say there aren't any issues, of course. (*) http://www.dabeaz.com/python/GIL.pdf (**) http://www.nabble.com/Mutex-performance-td24892454.html -- http://mail.python.org/mailman/listinfo/python-list
