[Cython] cython.parallel tasks, single, master, critical, barriers
Dag Sverre Seljebotn
d.s.seljebotn at astro.uio.no
Thu Oct 20 11:35:50 CEST 2011
On 10/20/2011 11:13 AM, mark florisson wrote:
> On 20 October 2011 09:42, Dag Sverre Seljebotn
> <d.s.seljebotn at astro.uio.no> wrote:
>> Meta: I've been meaning to respond to this thread, but can't find the time.
>> What's the time-frame for implementing this? If it's hypothetical at the
>> moment and just is a question of getting things spec-ed, one could perhaps
>> look at discussing it at the next Cython workshop, or perhaps a Skype call
>> with the three of us as some point...
> For me this is just about getting this spec-ed, so that when someone
> finds the time, we don't need to discuss it for weeks first. And the
> implementor won't necessarily have to support everything at once, e.g.
> just critical sections or barriers alone would be nice.
> Is there any plan for a new workshop then? Because if it's in two
> years I think we could be more time-efficient :)
At least in William's grant there's plans for 2-3 Cython workshops, so
hopefully there's funding for one next year if we want to. We should ask
him before planning anything though.
>> Regarding the tasks: One of my biggest problems with Python is the lack of
>> an elegant syntax for anonymous functions. But since Python has that
>> problem, I feel it is not necesarrily something we should fix (by using the
>> with statements to create tasks). Sometimes Pythonic-ness is more important
>> than elegance (for Cython).
> I agree it's not something we should fix, I just think tasks are most
> useful in inline blocks and not in separate functions or closures.
> Although it could certainly work, I think it restricts more, leads to
> more verbose code and possibly questionable semantics, and on top of
> that it would be a pain to implement (although that should not be used
> as a persuasive argument). I'm not saying there is no elegant way
> other than with blocks, I'm just saying that I think closures are not
> the right thing for it.
>> In general I'm happy as long as there's a chance of getting things to work
>> in pure Python mode as well (with serial execution). So if, e.g., with
>> statements creating tasks have the same effect when running the same code
>> (serially) in pure Python, I'm less opposed (didn't look at it in detail).
> Yes, it would have the same effect. The thing with tasks (and OpenMP
> constructs in general) is that usually if your compiler ignores all
> your pragmas, your code just runs serially in the same way. The same
> would be true for the tasks in with blocks.
Short note: I like the vision of Konrad Hinsen:
The core idea is that the "task-ness" of a block of code is orthogonal
to the place you actually write it. That is, a block of code may often
either be fit for execution as a task, or not, depending on how heavy it
is (= values of arguments it takes in, not its contents).
He introduces the "async" expression to drive this point through.
I think "with task" is fine if used in this way, if you simply call a
function (which itself doesn't know whether it is a task or not). But
once you start to implement an entire function within the with-statement
there's a code-smell.
Anyway, it's growing on me. But I think his "async" expression is more
Pythonic in the way that it forces you away from making your code smell.
We could simply have
async(func)(arg, arg2, somekwarg=4)
(He also says "functional-style programming is better for parallization
than threads+locks", which I can kind of agree with but nobody tried to
make an efficient immutable array implementation suitable for numerical
computation yet to my knowledge... that's an interesting MSc or
PhD-topic, but I already have one :-) )
(Look at me, going along discussing when I really shouldn't -- see you
More information about the cython-devel