[Cython] prange CEP updated

[mark florisson]

On 11 April 2011 13:03, Dag Sverre Seljebotn <d.s.seljebotn at astro.uio.no> wrote:
> On 04/11/2011 01:02 PM, Dag Sverre Seljebotn wrote:
>>
>> On 04/11/2011 12:14 PM, mark florisson wrote:
>>>
>>> On 11 April 2011 12:08, Dag Sverre
>>> Seljebotn<d.s.seljebotn at astro.uio.no> wrote:
>>>>
>>>> On 04/11/2011 11:41 AM, mark florisson wrote:
>>>>>
>>>>> 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.
>>>>
>>>> Well, I actually need to do the per-thread cache thing I described in
>>>> the
>>>> CEP in my own codes, so it's not *that* special; it'd be nice to
>>>> support it.
>>>
>>> You need 'old_ell' and 'alpha' after the loop?
>>
>>
>> No...but I need the values to not be blanked out at the beginning of
>> each loop iteration!
>
> Sorry, I now realize that re-reading your email I may have misunderstood
> you. Anyway, no, I don't need lastprivate at all anywhere.

Right, so basically you can rewrite your example by introducing the
parallel block (which doesn't add an indentation level as you're
already using nogil) and assigning to your variables that need to be
firstprivate there. The only thing you miss out on is lastprivate
behaviour. So basically, the question is, do we want explicit syntax
for such a rare case (firstprivate + lastprivate)?

I must say, I found your previous argument of future shared
declarations persuasive enough to introduce explicit syntax.

> Dag Sverre
>
>>
>> Note that in the CEP, the implicitly thread-local variables are *not
>> available* before the first assignment in the loop. That is, code such
>> as this is NOT allowed:
>>
>> cdef double x
>> ...
>> for i in prange(10):
>> print x
>> x = f(x)
>>
>> We raise a compiler error in such cases if we can: The code above is
>> violating the contract that the order of execution of loop bodies should
>> not matter.
>>
>> In cases where we can't raise an error (because we didn't bother or
>> because it is not possible with a proof), we still initialize the
>> variables to invalid values (NaN for double) at the beginning of the
>> for-loop just to be sure the contract is satisfied.
>>
>> This was added to answer Stefan's objection to new types of implicit
>> scopes (and I agree with his concern).
>>
>> Dag Sverre
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>