On 04/05/2011 07:05 AM, Robert Bradshaw wrote:
On Mon, Apr 4, 2011 at 6:04 AM, Stefan Behnel<stefan...@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
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
