[Cython] cython.parallel tasks, single, master, critical, barriers

[Dag Sverre Seljebotn]

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:

http://www.euroscipy.org/talk/2011

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 
later.)

Dag Sverre