[Cython] CEP: prange for parallel loops

[Dag Sverre Seljebotn]

On 04/05/2011 07:05 AM, Robert Bradshaw wrote:
> On Mon, Apr 4, 2011 at 6:04 AM, Stefan Behnel<stefan_ml at behnel.de>  wrote:
>> Dag Sverre Seljebotn, 04.04.2011 13:53:
>>> On 04/04/2011 01:23 PM, Stefan Behnel wrote:
>>>> Dag Sverre Seljebotn, 04.04.2011 12:17:
>>>>> CEP up at http://wiki.cython.org/enhancements/prange
>>>> """
>>>> Variable handling
>>>>
>>>> Rather than explicit declaration of shared/private variables we rely on
>>>> conventions:
>>>>
>>>> * Thread-shared: Variables that are only read and not written in the loop
>>>> body are shared across threads. Variables that are only used in the else
>>>> block are considered shared as well.
>>>>
>>>> * Thread-private: Variables that are assigned to in the loop body are
>>>> thread-private. Obviously, the iteration counter is thread-private as
>>>> well.
>>>>
>>>> * Reduction: Variables that only used on the LHS of an inplace operator,
>>>> such as s above, are marked as targets for reduction. If the variable is
>>>> also used in other ways (LHS of assignment or in an expression) it does
>>>> instead turn into a thread-private variable. Note: This means that if
>>>> one, e.g., inserts printf(... s) above, s is turned into a thread-local
>>>> variable. OTOH, there is simply no way to correctly emulate the effect
>>>> printf(... s) would have in a sequential loop, so such code must be
>>>> discouraged anyway.
>>>> """
>>>>
>>>> What about simply (ab-)using Python semantics and creating a new inner
>>>> scope for the prange loop body? That would basically make the loop behave
>>>> like a closure function, but with the looping header at the 'right' place
>>>> rather than after the closure.
>>> I'm not quite sure what the concrete changes to the CEP this would lead to
>>> (assuming you mean this as a proposal for alternative semantics, and not
>>> an
>>> implementation detail).
>> What I would like to avoid is having to tell users "and now for something
>> completely different". It looks like a loop, but then there's a whole page
>> of new semantics for it. And this also cannot be used in plain Python code
>> due to the differing scoping behaviour.
> The same could be said of OpenMP--it looks exactly like a loop except
> for a couple of pragmas.
>
> The proposed (as I'm reading the CEP now) semantics of what's shared
> and first/last private and reduction would give it the semantics of a
> normal, sequential loop (and if your final result changes based on how
> many threads were involved then you've got incorrect code). Perhaps
> reading of the reduction variable could be fine (though obviously
> ill-defined, suitable only for debugging).

So would you disable inplace operators for thread-private variables? 
Otherwise a variable could be both a reduction variable and 
thread-private...

There's a reason I disabled reading the reduction variable (which I 
should have written down).

Dag Sverre