[Numpy-discussion] Fast threading solution thoughts
Dag Sverre Seljebotn
dagss@student.matnat.uio...
Thu Feb 12 13:32:02 CST 2009
Sturla Molden wrote:
> On 2/12/2009 12:34 PM, Dag Sverre Seljebotn wrote:
>
>> FYI, I am one of the core Cython developers and can make such
>> modifications in Cython itself as long as there's consensus on how it
>> should look on the Cython mailing list. My problem is that I don't
>> really know OpenMP and have little experience with it, so I'm not the
>> best person for creating a draft for how such high-level OpenMP
>> constructs should look like in Cython.
>
> I don't know the Cython internals, but I do know OpenMP. I mostly use it
> with Fortran.
>
> The question is: Should OpenMP be comments in the Cython code (as they
> are in C and Fortran), or should OpenMP be special objects?
Statements more or less like C and Fortran, but "disguised" as Python
syntax rather than pragmas/comments.
> As for the GIL: No I don't think nogil should be implied. But Python
> objects should only be allowed as shared variables. Synchronization will
> then be as usual for shared variables in OpenMP (#pragma omp critical).
Good point.
> Here is my suggestion for syntax. If you just follow a consistent
> translation scheme, you don't need to know OpenMP in details. Here is a
> suggestion:
>
>
> with openmp('parallel for', argument=iterable, ...):
> --> insert pragma directly above for
>
> with openmp(directive, argument=iterable, ...):
> --> insert pragma and brackets
>
> with openmp('atomic'): --> insert pragma directly
>
> openmp('barrier') --> insert pragma directly
>
>
> This by the way covers all of OpenMP. This is how it should translate:
>
>
> with openmp('parallel for', private=(i,), shared=(n,),
IMO there's a problem with using literal variable names here, because
Python syntax implies that the value is passed. One shouldn't make
syntax where private=(i,) is legal but private=(f(),) isn't. So I'd go
for strings.
> schedule='dynamic'):
>
> for i in range(n):
> pass
>
> Compiles to:
>
> #pragma omp parallel for \
> private(i) \
> shared(n) \
> schedule(dynamic)
> for(i=0; i<n; i++) {
> /* whatever */
> }
Hmm... yes. Care would need to be taken though because Cython might in
the future very well generate a "while" loop instead for such a
statement under some circumstances, and that won't work with OpenMP. One
should be careful with assuming what the C result will be of Cython
code. That's why I proposed using an alternative construct which both
does the OpenMP stuff and contains the for loop.
> With Python objects, the programmer must synchronize access:
>
>
> with openmp('parallel for', shared=(pyobj,n), private=(i,)):
> for i in range(n):
> with openmp('critical'):
> pyobj += i
We already have the nogil stuff, so with e.g. "with openmp.critical:"
instead we would leave the way open for checking correctness in this area.
Anyway, thanks for the input. I've made it a ticket and might get back
to it when I've got more time through a discussion on the Cython list.
http://trac.cython.org/cython_trac/ticket/211
--
Dag Sverre
More information about the Numpy-discussion
mailing list