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