[Python-Dev] Pythonic concurrency

Michael Sparks ms at cerenity.org
Sat Oct 8 12:44:00 CEST 2005

On Saturday 08 October 2005 04:05, Josiah Carlson wrote:
[ simplistic, informal benchmark of a test optimised versioned of the system,
 based on bouncing scaing rotating sprites around the screen. ]
> Single process?  Multi-process single machine?  Multiprocess multiple
> machine?

SIngle process, single CPU, not very recent machine. (600MHz crusoe based 
machine so) That machine wasn't hardware accelerated though, so was only able 
to handle several dozen sprites before slowing down. The slowdown was due to 
the hardware not being able to keep up with pygame's drawing requests though 
rather than the framework.

> I'm just offering the above as example benchmarks (you certainly don't
> need to do them to satisfy me, but I'll be doing those when my tuple
> space implementation is closer to being done).

I'll note them as things worth doing - they look reasonable and interesting
benchmarks. (I can think of a few modifications I might make though. For
example in 3 you say "fastest". I might have that as a 3b. 3a could be
"simplest to use/read" or "most likely to pick". Obviously there's a good
chance that's not the fastest. (Could be optimised to be under the hood
I suppose, but that wouldn't be the point of the test)

> > [ Network controlled Networked Audio Mixing Matrix ]
> I imagine you are using a C library/extension of some sort to do the
> mixing...perhaps numarray, Numeric, ... 

Nope, just plain old python (I'm now using a 1.6Ghz centrino machine
though). My mixing function is particularly naive as well. To me that says
more about python than my code. I did consider using pyrex to wrap (or
write) an optimised version, but there didn't seem to be any need for
last week (Though for a non-prototype something faster would be
nice :).

I'll save responding the linda things until I have a chance to read in detail
what you've written. It sounds very promising though - having multiple
approaches to different styles of concurrency that work nicely with each
other safely is always a positive thing IMO.

Thanks for the suggestions and best regards,

"Though we are not now that which in days of old moved heaven and earth, 
   that which we are, we are: one equal temper of heroic hearts made 
     weak by time and fate but strong in will to strive, to seek, 
          to find and not to yield" -- "Ulysses", Tennyson

More information about the Python-Dev mailing list