[Cython] prange CEP updated

[Dag Sverre Seljebotn]

On 04/11/2011 01:12 PM, mark florisson wrote:
> 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)?

OK, we're on the same page here.

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

OK, lets leave it at this then, we don't have to agree for the same 
reasons :-)

Dag Sverre