[Cython] prange CEP updated

[Dag Sverre Seljebotn]

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.

Dag Sverre