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? > OTOH I *could* work around it by having an array of scalars > > cdef int[:] old_ell = int[:numthreads]() > > ... > if old_ell[threadid()] != ell: ... > > > So I guess, it's at least on the bottom of list of priorities in that CEP. > > Dag Sverre > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
