[Python-Dev] Pythonic concurrency

[Josiah Carlson]

Michael Sparks <ms at cerenity.org> wrote:
> On Saturday 08 October 2005 04:05, Josiah Carlson wrote:
> > 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)

Good point.
3a. Use 1024 byte blocks...
3b. Use whatever makes your system perform best (if you have the time to
tune it)...


> > > [ 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 :).

Indeed.  A quick array.array('h',...) implementation is able to run 7-8x
real time on 3->1 stream mixing on my 1.3 ghz laptop.  Maybe numeric or
numarray isn't necessary.


> 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,

Thank you for the interesting and informative discussion.

 - Josiah