[Cython] prange CEP updated

[mark florisson]

On 11 April 2011 11:10, Dag Sverre Seljebotn <d.s.seljebotn at astro.uio.no> wrote:
> 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.

Indeed, I actually considered if we should support firstprivate at
all, as it's really about "being firstprivate and lastprivate".
Without any declaration, you can have firstprivate or lastprivate, but
not both :) So I agree that supporting such a (probably) uncommon case
is better left explicit. On the other hand it seems silly to have
support for such a weird case.

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

Right, everything is implicit. So I guess it'll be good to introduce
it anyway as you say, so we can later declare stuff shared with
similar syntax. I suppose that's the point where I'm convinced.

> That's just my opinion, I'm happy to be overruled here.
>
> Dag Sverre
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>