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. > (The other instance of thread-local variables I feel is still explicit: You > use prange instead of range, which means that you declare that values > created in the iteration does not leak to the next iteration. The rest is > just optimization from there.) > > As Robert said in his recent talk: A lot of languages are easy to write. The > advantage of Python is that it is easy to *read*. That's what I feel is > wrong with the proposal above: An assignment to a variable changes the > semantics of it. Granted, it happens in a way so that it will almost always > be correct, but I feel that reading the code, I'd spend some extra cycles to > go "ah, so this variable is thread-local and therefore its values survive > across a loop iteration". > > If I even knew about the feature in the first place. In seeing > "threadprivate" spelled out, it is either obvious what it means, or obvious > that I should look up the docs. > > There's *a lot* of things that can be made implicit in a programming > language; Python/Cython simply usually leans towards the explicit side. > > Oh, and we may want to support writable shared variables (and flush) > eventually too, and the above doesn't easily differentiate there? Right, everything is implicit. So I guess it'll be good to introduce it anyway as you say, so we can later declare stuff shared with similar syntax. I suppose that's the point where I'm convinced. > That's just my opinion, I'm happy to be overruled here. > > 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
