On Mon, Oct 10, 2011 at 1:12 AM, mark florisson <markflorisso...@gmail.com> wrote: > On 9 October 2011 22:27, mark florisson <markflorisso...@gmail.com> wrote: >> >> On 9 October 2011 21:48, Jon Olav Vik <jono...@gmail.com> wrote: >> > On Sun, Oct 9, 2011 at 9:01 PM, mark florisson >> > <markflorisso...@gmail.com> wrote: >> >> On 9 October 2011 19:54, Jon Olav Vik <jono...@gmail.com> wrote: >> >>> Personally, I think I'd prefer context managers as a very >> >>> readable way to deal with parallelism >> >> >> >> Yeah it makes a lot of sense for mutual exclusion, but 'master' really >> >> means "only the master thread executes this peace of code, even though >> >> other threads encounter the same code", which is more akin to 'if' >> >> than 'with'. >> > >> > I see your point. However, another similarity with "with" statements >> > as an encapsulated "try..finally" is when there's a barrier at the end >> > of the block. I can live with some magic if it saves me from having a >> > boilerplate line of "barrier" everywhere 8-) >> > _______________________________________________ >> > cython-devel mailing list >> > cython-devel@python.org >> > http://mail.python.org/mailman/listinfo/cython-devel >> > >> >> Hm, indeed. I just noticed that unlike single constructs, master >> constructs don't have barriers. Both are also not allowed to be >> closely nested in worksharing constructs. I think the single directive >> is more useful with respect to tasks, e.g. have a single thread >> generate tasks and have other threads waiting at the barrier execute >> them. In that sense I suppose 'if parallel.is_master():' makes sense >> (no barrier, master thread) and 'with single():' (with barrier, any >> thread). >> >> We could still support single in prange though, if we simply have the >> master thread execute it ('if (omp_get_thread_num() == 0)') and put a >> barrier after the block. This makes me wonder what the point of master >> was supposed to be... > > Scratch that last part about master/single in parallel sections, it > doesn't make sense. It only makes sense if you think of those sections > as tasks you submit that would be immediately taken up by a (certain) > thread. But that's not quite what it means. I do like 'if is_master()' > and 'with single', though. > > Another thing we could support is arbitrary reductions. In OpenMP 3.1 > you get reduction operators 'and', 'max' and 'min', but it wouldn't be > hard to support arbitrary user functions. e.g. > > @cython.reduction > cdef int func(int a, int b): > ... > > for i in prange(...): > a = func(a, b)
Interesting idea. An alternative syntax could be a = cython.parallel.reduce(func, a, b) > I'm not sure how common this is though. You probably have your > reduction data in an array so you're already using numpy so you'll > likely already have your functionality. > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
