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