Moving towards Python 3.0 (was Re: [Python-Dev] Speed up function calls) (original) (raw)

Donovan Baarda abo at minkirri.apana.org.au
Tue Feb 1 03:06:34 CET 2005

On Tue, 2005-02-01 at 10:30 +1100, Donovan Baarda wrote:

On Mon, 2005-01-31 at 15:16 -0500, Nathan Binkert wrote: > > Wouldn't it be nicer to have a facility that let you send messages > > between processes and manage concurrency properly instead? You'll need [...] A quick google search revealed this;

http://www.heise.de/ct/english/98/13/140/ Keeping in mind the high overheads of sharing memory between CPU's, the discussion about threads at this url seems to confirm; threads with shared memory are hard to distribute over multiple CPU's. Different OS's and/or thread implementations have tried (or just outright rejected) different ways of doing it, to varying degrees of success. IMHO, the fact that QNX doesn't distribute threads speaks volumes.

Sorry for replying to my reply, but I forgot the bit that brings it all back On Topic :-)

The belief that the opcode granularity thread-switch driven by the GIL is the cause of Python's threads being non-distributable is only half true.

Since OS's don't distribute threads well, any attempts to "Fix Python's Threading" in an attempt to make its threads distributable is a waste of time. The only thing that this might achieve would be to reduce the latency on thread switches, maybe allowing faster response to OS events like signals. However, the complexity introduced would cause more problems than it would fix, and could easily result in worse performance, not better.

-- Donovan Baarda <abo at minkirri.apana.org.au> http://minkirri.apana.org.au/~abo/

More information about the Python-Dev mailing list