[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