On May 17, 7:05 am, jer...@martinfamily.freeserve.co.uk wrote:
> From a user point of view I think that adding a 'par' construct to
> Python for parallel loops would add a lot of power and simplicity,
> e.g.
>
> par i in list:
> updatePartition(i)
>
> There would be no locking and it would be the programmer's
> responsibility to ensure that the loop was truly parallel and correct.
>
> The intention of this would be to speed up Python execution on multi-
> core platforms. Within a few years we will see 100+ core processors as
> standard and we need to be ready for that.
>
> There could also be parallel versions of map, filter and reduce
> provided.
>
> BUT...none of this would be possible with the current implementation
> of Python with its Global Interpreter Lock, which effectively rules
> out true parallel processing.
>
> See:http://jessenoller.com/2009/02/01/python-threads-and-the-global-inter...
>
> What do others think?
>
> Jeremy Martin
Hi, joining late.
My first guess is that you haven't considered the existing syntactic
variants.
for i in list:
fireandforget( updatePartition )( i )
for i in list:
with fireandforget( ) as x:
x.call( updatePartition )( i )
@fireandforget
def fun( i ):
updatePartition( i )
for i in list:
fun( i )
Are you suggesting only syntactic sugar, or a true semantic change to
make parallel programming easier?
--
http://mail.python.org/mailman/listinfo/python-list
