[Cython] prange CEP updated

Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no
Mon Apr 11 13:03:37 CEST 2011


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.

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



More information about the cython-devel mailing list