[Cython] prange CEP updated

[Dag Sverre Seljebotn]

On 04/11/2011 10:45 AM, mark florisson wrote:
> On 5 April 2011 22:29, Dag Sverre Seljebotn<d.s.seljebotn at astro.uio.no>  wrote:
>> I've done a pretty major revision to the prange CEP, bringing in a lot of
>> the feedback.
>>
>> Thread-private variables are now split in two cases:
>>
>>   i) The safe cases, which really require very little technical knowledge ->
>> automatically inferred
>>
>>   ii) As an advanced feature, unsafe cases that requires some knowledge of
>> threading ->  must be explicitly declared
>>
>> I think this split simplifies things a great deal.
>
> Can't we obsolete the declaration entirely by assigning to variables
> that need to have firstprivate behaviour inside the with parallel
> block? Basically in the same way the scratch space is used. The only
> problem with that is that it won't be lastprivate, so the value will
> be undefined after the parallel block (but not after the worksharing
> loop).
>
> cdef int myvariable
>
> with nogil, parallel:
>      myvariable = 2
>      for i in prange(...):
>          use myvariable
>          maybe assign to myvariable
>
>      # myvariable is well-defined here
>
> # myvariable is not well-defined here
>
> If you still desperately want lastprivate behaviour you can simply
> assign myvariable to another variable in the loop body.

I don't care about lastprivate, I don't think that is an issue, as you say.

My problem with this is that it means going into an area where possibly 
tricky things are implicit rather than explicit. I also see this as a 
rather special case that will be seldomly used, and implicit behaviour 
is more difficult to justify because of that.

(The other instance of thread-local variables I feel is still explicit: 
You use prange instead of range, which means that you declare that 
values created in the iteration does not leak to the next iteration. The 
rest is just optimization from there.)

As Robert said in his recent talk: A lot of languages are easy to write. 
The advantage of Python is that it is easy to *read*. That's what I feel 
is wrong with the proposal above: An assignment to a variable changes 
the semantics of it. Granted, it happens in a way so that it will almost 
always be correct, but I feel that reading the code, I'd spend some 
extra cycles to go "ah, so this variable is thread-local and therefore 
its values survive across a loop iteration".

If I even knew about the feature in the first place. In seeing 
"threadprivate" spelled out, it is either obvious what it means, or 
obvious that I should look up the docs.

There's *a lot* of things that can be made implicit in a programming 
language; Python/Cython simply usually leans towards the explicit side.

Oh, and we may want to support writable shared variables (and flush) 
eventually too, and the above doesn't easily differentiate there?

That's just my opinion, I'm happy to be overruled here.

Dag Sverre