On Thu, Apr 21, 2011 at 2:21 AM, mark florisson <markflorisso...@gmail.com> wrote: > On 21 April 2011 10:59, mark florisson <markflorisso...@gmail.com> wrote: >> On 21 April 2011 10:37, Robert Bradshaw <rober...@math.washington.edu> wrote: >>> On Mon, Apr 18, 2011 at 7:51 AM, mark florisson >>> <markflorisso...@gmail.com> wrote: >>>> On 18 April 2011 16:41, Dag Sverre Seljebotn <d.s.seljeb...@astro.uio.no> >>>> wrote: >>>>> Excellent! Sounds great! (as I won't have my laptop for some days I can't >>>>> have a look yet but I will later) >>>>> >>>>> You're right about (the current) buffers and the gil. A testcase >>>>> explicitly >>>>> for them would be good. >>>>> >>>>> Firstprivate etc: i think it'd be nice myself, but it is probably better >>>>> to >>>>> take a break from it at this point so that we can think more about that >>>>> and >>>>> not do anything rash; perhaps open up a specific thread on them and ask >>>>> for >>>>> more general input. Perhaps you want to take a break or task-switch to >>>>> something else (fused types?) until I can get around to review and merge >>>>> what you have so far? You'll know best what works for you though. If you >>>>> decide to implement explicit threadprivate variables because you've got >>>>> the >>>>> flow I certainly wom't object myself. >>>>> >>>> Ok, cool, I'll move on :) I already included a test with a prange and >>>> a numpy buffer with indexing. >>> >>> Wow, you're just plowing away at this. Very cool. >>> >>> +1 to disallowing nested prange, that seems to get really messy with >>> little benefit. >>> >>> In terms of the CEP, I'm still unconvinced that firstprivate is not >>> safe to infer, but lets leave the initial values undefined rather than >>> specifying them to be NaNs (we can do that as an implementation if you >>> want), which will give us flexibility to change later once we've had a >>> chance to play around with it. >> >> Yes, they are currently undefined (and not initialized to NaN etc). >> The thing is that without the control flow analysis (or perhaps not >> until runtime) you won't know whether a variable is initialized at all >> before the parallel section, so making it firstprivate might actually >> copy an undefined value (perhaps with a trap representation!) into the >> thread-private copy, which might invalidate valid code. e.g. consider >> >> x_is_initialized = False >> if condition: >> x = 1 >> x_is_initialized = True >> >> for i in prange(10, schedule='static'): >> if x_is_initialized: >> printf("%d\n", x) >> x = i > > Erm, that snippet I posted is invalid in any case, as x will be > private. So guess initializing things to NaN in such would have to > occur in the parallel section that should enclose the for. So e.g. > we'd have to do > > #pragma omp parallel private(x) > { > x = INT_MAX; > #pragma omp for lastprivate(i) > for (...) > ... > } > > Which would then mean that 'x' cannot be lastprivate anymore :). So > it's either "uninitialized and undefined" or "firstprivate". I > personally prefer the former for the implicit route.
A variable can't be both first and last private? In any case, as long as we don't promise anything about them now, we can decide later. > I do like the threadlocal=a stuff to parallel, it's basically what I > proposed a while back except that you don't make them strings, but > better because most of your variables can be inferred, so the > messiness is gone. Yep. - Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel