Parallel processing

[Corey Coughlin]

Josiah Carlson <jcarlson at uci.edu> wrote in message news:<mailman.6501.1100717187.5135.python-list at python.org>...
> 
> There are various other reasons why Python is not as parallelizable as
> you would think.  Among them is the semantics of scoping, and whether
> there is shared or unshared scope among the processors/nodes.  If shared,
> then any operation that could change scopes would need to be distributed
> (ick), or if unshared, then you are basically looking at an
> automatically distributed tuplespace (LINDA).  It gets even uglier with
> certain kinds of generators.
> 
> Regardless of which one is the case, heavy modifications to Python would
> necessarily need to be done in order to make them happen.
> 
> 
>  - Josiah

Well, I'm not sure it's necessarily that grim.  Generally, taking an
inference engine something like that proposed for Starkiller, tracking
variable types as closely as possible, adding some data flow
capability to follow the execution path, you could probably do
something useful.  With Python's for..in loop syntax, the prohibition
against chaning loop variables there, and list comprehensions,
parallelized loop unrolling, done intelligently, could help out a lot
on parallel architectures.  Sure, it'd be hard to do effectively in a
strictly interpreted environment, but if Starkiller ever comes out, it
seems almost inevitable.  Then again, that project seems to be getting
later all the time.  :(