[Cython] OpenMP support

mark florisson markflorisson88 at gmail.com
Tue Mar 8 17:33:47 CET 2011

On 8 March 2011 16:28, Dag Sverre Seljebotn <d.s.seljebotn at astro.uio.no> wrote:
> 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.)

I would love to participate, the problem is that I'm really not sure
whether it will fit in my schedule. I will certainly figure this out.

>> 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

With OpenMP code, exactly how common are exceptions and error handling?
I agree that listing privates that way doesn't look very appealing.
Maybe 'private=(a, b)' is somewhat better. Or perhaps we should really
divert to syntax like

cython.openmp("parallel sections private(a, b)"):

and implement a little OpenMP pragma parser (which shouldn't be very hard).

> 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 think OpenMP is not really designed for error handling, so if we'd
go the OpenMP route I think the only way to support exceptions would
be to save a pending exception, and "raise" it after the construct
ends (in the sequential part), just outside the nogil block (in which
case it makes sense to make directives implicitly nogil).
Perhaps we can allow GIL acquisition in master constructs and as you
mentioned on the wiki, default critical constructs. Exceptions would
of course remain pending. Perhaps it's possible to guard against that,
i.e., finish the OpenMp construct but skip the actual work in case of
a pending exception. I must say, it doesn't sound very promising.

So I think we should also ask ourselves what users want, i.e., do they
usually want to deal with Python objects in their worksharing code, or
do they often want to deal with raw C data? I don't know the answer
but I'm guessing they want both. But if users want to deal with Python
objects, they could use multiprocessing (although if they wanted to
share a lot of data they might have to deal with pickling overhead).

> 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
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel

More information about the cython-devel mailing list