[Cython] OpenMP support

[Dag Sverre Seljebotn]

On 03/08/2011 11:34 AM, mark florisson wrote:
> I'd like to implement OpenMP support for Cython. Looking at

Great news! It looks like this will be a topic on the coming workshop, 
with Francesc coming as well (but nothing wrong with getting started 
before then).

(And please speak up if you are in the right group for a GSoC.)

> http://wiki.cython.org/enhancements/openmp I agree a close
> 1:1 mapping would be nice. It would probably make sense to start with
> support for 'nogil' sections because GIL-holding
> sections would be hard to deal with considering all the 'goto's that
> are generated (because you may not leave the
> OpenMP block). See this thread
> http://comments.gmane.org/gmane.comp.python.cython.devel/8695 for a
> previous discussion.
>
> Looking also at http://wiki.cython.org/enhancements/parallel , for the
> 'parallel for' support I think the best syntax would
> be to introduce a fake 'cython.openmp' module as Dag suggested. I
> propose to start with the following syntax:
>
>      from python (c)import openmp
>
>      with nogil:
>          with openmp.parallel('sections'):
>              with openmp.section():

I've changed my opinion a little bit since that thread; I'm now rather 
undecided.

Pros:

  - Easy to get results fast (nothing wrong about Sturla's approach, but 
realistically it *will* take longer to make it work)
  - OpenMP already has significant mindshare. Saying "Cython supports 
OpenMP" will sound soothing to scientific Fortran and C programmers, 
even if it is technically inferior to other solutions we could find.

Cons:

  - Like Sturla says, closures maps this better in the Cython language 
(having "private=('a', 'b')" as a syntax for referring to the local 
variables a and b is rather ugly)
  - The goto restriction that makes exception handling harder

I think that long-term we must find some middle ground that sits between 
just having the GIL and not having it. E.g., find some way of raising an 
exception from a nogil block, and also allow more simple code to "get 
more data to work on" within the context of a single thread. So what 
you're saying about goto's making me lean against OpenMP.

But, perfect is the enemy of good. I certainly won't vote against having 
this implemented -- because *anything* is better than nothing, and 
nothing prevents us from building something better in addition to or on 
top of an initial OpenMP implementation.

BTW, I found this framework interesting ...  it cites some other 
frameworks as well (cilk, OpenMP, Intel Threading Blocks), which it 
beats in a specific situation.

http://calvados.di.unipi.it/dokuwiki/doku.php?id=ffnamespace:about

I'm NOT saying we should "support FastFlow instead". What I'm thinking 
is that perhaps the place to start is to ask ourselves: What are the 
current obstacles to using parallelization frameworks written for C or 
C++ with Cython? How would one use Cython with these, and do it in a 
practical way (i.e. not just C code in a nogil block without even 
exception handling).

I.e. what I'd like to tackle first (and perhaps on the workshop) is how 
to even make it a somewhat pleasant experience to use pthreads or Python 
threading. Set signal handlers for SIGTERM and friends, implement some 
form of "delayed" exception creation so that we first pop the stack, 
acquire the GIL, and *then* construct the exception object...

But this is perhaps orthogonal to an OpenMP effort.

Dag Sverre