On 04/11/2011 12:14 PM, mark florisson wrote:
On 11 April 2011 12:08, Dag Sverre Seljebotn<d.s.seljeb...@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.seljeb...@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.seljeb...@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!
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@python.org
http://mail.python.org/mailman/listinfo/cython-devel
