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
