On 05/04/2011 08:07 PM, mark florisson wrote:
On 4 May 2011 19:44, Dag Sverre Seljebotn<d.s.seljeb...@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.seljeb...@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
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel