On 4 May 2011 21:13, Dag Sverre Seljebotn <d.s.seljeb...@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.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.
Ok, sure, that's fine with me. _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
