[Cython] prange CEP updated

[mark florisson]

On 4 May 2011 21:13, Dag Sverre Seljebotn <d.s.seljebotn at astro.uio.no> wrote:
> On 05/04/2011 08:07 PM, mark florisson wrote:
>>
>> On 4 May 2011 19:44, Dag Sverre Seljebotn<d.s.seljebotn at astro.uio.no>
>>  wrote:
>>>
>>> On 05/04/2011 07:03 PM, mark florisson wrote:
>>>>
>>>> On 4 May 2011 18:35, Dag Sverre Seljebotn<d.s.seljebotn at astro.uio.no>
>>>>  wrote:
>>>>>
>>>>> Moving pull requestion discussion
>>>>> (https://github.com/cython/cython/pull/28)
>>>>> over here:
>>>>>
>>>>> First, I got curious why you'd have a strip off "-pthread" from CC. I'd
>>>>> think you could just execute with it with "-pthread", which seems
>>>>> simpler.
>>>>
>>>> It needs to end up in a list of arguments, and it's not needed at all
>>>> as I only need the version. I guess I could do (cc + " -v").split()
>>>> but eh.
>>>
>>> OK, that's reassuring, thought perhaps you had encountered a strange gcc
>>> strain.
>>>
>>>>
>>>>> Second: If parallel.parallel is not callable, how are scheduling
>>>>> parameters
>>>>> for parallel blocks handled? Is there a reason to not support that? Do
>>>>> you
>>>>> think it should stay this way, or will parallel take parameters in the
>>>>> future?
>>>>
>>>> Well, as I mentioned a while back, you cannot schedule parallel
>>>> blocks, there is no worksharing involved. All a parallel block does is
>>>> executed a code block in however many threads there are available. The
>>>> scheduling parameters are valid for a worksharing for loop only, as
>>>> you schedule (read "distribute") the work among the threads.
>>>
>>> Perhaps I used the wrong terms; but checking the specs, I guess I meant
>>> "num_threads", which definitely applies to parallel.
>>
>> Ah, that level of scheduling :) Right, so it doesn't take that, but I
>> don't think it's a big issue. If dynamic scheduling is enabled, it's
>> only a suggestion, if dynamic scheduling is disabled (whether it's
>> turned on or off by default is implementation defined) it will give
>> the the amount of threads requested, if available.
>> The user can still use omp_set_num_threads(), although admittedly that
>> modifies a global setting.
>
> Hmm...I'm not completely happy about this. For now I just worry about not
> shutting off the possibility of adding thread-pool-spawning parameters in
> the future. Specifying the number of threads can be useful, and
> omp_set_num_threads is a bad way of doing as you say.
>
> And other backends than OpenMP may call for something we don't know what is
> yet?
>
> Anyway, all I'm asking is whether we should require trailing () on parallel:
>
> with nogil, parallel(): ...
>
> I think we should, to keep the window open for options. Unless, that is,
> we're OK both with and without trailing () down the line.

Ok, sure, that's fine with me.