Auto-parallelizing without decorators?

[John Nagle]

Kirk Strauser wrote:
> I was thinking about how a lot of Lisp proponents claim that Lisp is
> inherently parallelizable because its functions don't have (or are not
> supposed to have) side effects, and therefore the compiler can easily tell
> which calls may be run in parallel instead of strictly serially.  I'm not a
> Lisp expert so I can't say whether that's true or not, but it seems like an
> interesting idea for Python.
> 
> Suppose that Python had a new decorator, say "@parallelizable".  Functions
> so decorated would be eligible for multi-processed or multi-threaded
> execution by such native constructs as list comprehensions, or the map()
> function.

    That implies much smarter compilers than we've seen to date for Python.

    A more useful idea might be to provide a map/reduce library in the
sense that Google uses the term.

    Google's concept of "map/reduce" is that the mapped function is applied
to all the elements of the list simultaneously, up to the limits of resources
available.  The result of each function is a name/value tuple.  The
reduction process consists of collecting all tuples with the same name
and feeding them to copies of the "reduce" function in no particular order,
with the "reduce" function producing fewer output tuples than input tuples.
The "reduce" function is applied repeatedly in a tree sense until all
output tuples have been reduced.

    See:

	http://labs.google.com/papers/mapreduce.html

    Contrast this with Python's "reduce", which is inherently sequential.

					John Nagle