> > The annotations will be > > added to only certain predefined type of loops since parallel iteration > over > > generic objects is not possible. > > It's not necessarily impossible. Take one thread that iterates over the > iterable and hands each item to a somewhat long-running worker thread.
Aah ok. Thats basically like a producer and multiple consumer kind of scenario? Didnt think of that. > > > I do not know if Cython has such a facility. > > No. > > > > My original suggestion : > > > > "pragma parallel for" > > for i in xrange(n):x[i] = y[i] > > I like the fact that it uses a string instead of a comment. However, I > would > prefer having a real syntax in Cython. > > > > with parallel(i): > > for i in xrange(n):x[i] = y[i] > > Since we already have "with (no)gil", this would match nicely. Still, a > syntax > inside the loop header would be preferable to keep the link with the actual > thing that runs in parallel, which is just the loop and nothing else inside > the "with" block. > > > > I think we can also do something like : > > > > for i in prange(i): x[i] = y[i] > > > > prange can simply default to xrange when running on the interpreter but > the > > compiler can think of prange as a special object. > > But that would mean you'd have to change the code or at least provide the > name > "prange" to make it run in Python, in which case there is less gain in > keeping > up a Python-compatible syntax. > I was thinking of providing a "prange" which defaults to xrange when running on interpreter. The reason I like the prange construct, is that we can easily add lets say thread-local variables or reduction variables. for i in prange(i, threadlocal=[myvar1,myvar2],reduction=[red1,red2]): #loop body Even "with parallel" or "with nogil", we need to define "parallel" or nogil in some module so that it runs on python. Hmm, I guess we can also provide keyword arguments with parallel() or nogil()? > > > > Semantics needs to be defined properly. For example, exceptions cannot be > > raised in proper order in parallel loops. > > Order doesn't matter in non-synchronised parallel execution, but I would > expect them to be thread-local anyway. If you want to catch an exception > raised in a parallel loop, I'm fine with doing so inside the loop and > loosing > the exception when the loop ends. Ok. I guess thats reasonable. > > > Any ideas/suggestions/flames? OpenMP has many more features such as > > reduction variables. OpenMP is a very simple parallel programming model > and > > introducing something similar in Python can be really helpful. > > > > For an implementation perspectives, it will be a little challenging to > > generate code while avoiding the GIL but it can be done in simple cases. > > It may even be enough to require "nogil" for parallel execution in the > beginning. I expect the GIL overhead to be too high for simple loops and I > don't think you'd write bigger things as a loop. When I use threads in > Python, > I'm usually quite considerate about the minimum amount of work that gets > parallelised. > Can you clarify this? Or give an example? I think I will host this as a wiki page somewhere so that people can easily edit it. thanks, rahul
_______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
