Re: [Cython] cython.parallel tasks, single, master, critical, barriers
On 9 October 2011 22:27, mark florisson wrote:
>
> On 9 October 2011 21:48, Jon Olav Vik wrote:
> > On Sun, Oct 9, 2011 at 9:01 PM, mark florisson
> > wrote:
> >> On 9 October 2011 19:54, Jon Olav Vik wrote:
> >>> Personally, I think I'd prefer context managers as a very
> >>> readable way to deal with parallelism
> >>
> >> Yeah it makes a lot of sense for mutual exclusion, but 'master' really
> >> means "only the master thread executes this peace of code, even though
> >> other threads encounter the same code", which is more akin to 'if'
> >> than 'with'.
> >
> > I see your point. However, another similarity with "with" statements
> > as an encapsulated "try..finally" is when there's a barrier at the end
> > of the block. I can live with some magic if it saves me from having a
> > boilerplate line of "barrier" everywhere 8-)
> > ___
> > cython-devel mailing list
> > cython-devel@python.org
> > http://mail.python.org/mailman/listinfo/cython-devel
> >
>
> Hm, indeed. I just noticed that unlike single constructs, master
> constructs don't have barriers. Both are also not allowed to be
> closely nested in worksharing constructs. I think the single directive
> is more useful with respect to tasks, e.g. have a single thread
> generate tasks and have other threads waiting at the barrier execute
> them. In that sense I suppose 'if parallel.is_master():' makes sense
> (no barrier, master thread) and 'with single():' (with barrier, any
> thread).
>
> We could still support single in prange though, if we simply have the
> master thread execute it ('if (omp_get_thread_num() == 0)') and put a
> barrier after the block. This makes me wonder what the point of master
> was supposed to be...
Scratch that last part about master/single in parallel sections, it
doesn't make sense. It only makes sense if you think of those sections
as tasks you submit that would be immediately taken up by a (certain)
thread. But that's not quite what it means. I do like 'if is_master()'
and 'with single', though.
Another thing we could support is arbitrary reductions. In OpenMP 3.1
you get reduction operators 'and', 'max' and 'min', but it wouldn't be
hard to support arbitrary user functions. e.g.
@cython.reduction
cdef int func(int a, int b):
...
for i in prange(...):
a = func(a, b)
I'm not sure how common this is though. You probably have your
reduction data in an array so you're already using numpy so you'll
likely already have your functionality.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] PyCon-DE wrap-up by Kay Hayen
mark florisson, 09.10.2011 19:57: On 9 October 2011 18:35, Stefan Behnel wrote: One of the impressions I took out of the technical discussions with Kay is that there isn't really a good reason why Cython should refuse to duplicate some of the inner mechanics of CPython for optimisation purposes. Nuitka appears to be somewhat more aggressive here, partly because Kay doesn't currently care all that much about portability (e.g. to Python 3). Interesting. What kind of (significant) optimizations could be made by duplicating code? Do you want to duplicate entire functions or do you want to inline parts of those? I was mainly referring to things like direct access to type/object struct fields and little things like that. They can make a difference especially in loops, compared to calling into a generic C-API function. For example, we could have our own interned implementation of PyDict_Next(). I'm not very impressed by the performance of that C-API function - repeated calls to GetItem can be faster than looping over a dict with PyDict_Next()! That being said, I wasn't referring to any specific changes. It was more of a general remark about the invisible line that we currently draw in Cython. I actually think we should not get too tied to CPython, e.g. what if PyPy gets a CPython compatible API It already implements a part of the C-API: http://morepypy.blogspot.com/2010/04/using-cpython-extension-modules-with.html However, if we really want to support it at that level, there's likely more to do than just removing low-level optimisations. And that would take the normal route that we always use: macros and conditionally compiled inline functions. The mere fact that we try to support different targets doesn't mean that we should stop optimising for specific targets. The same is true for different versions of CPython, where we often use better optimisations in newer releases, without sacrificing backwards compatibility. Personally, I think that supporting PyPy at the Python level is a lot more interesting, although it may be easier to get it working at the cpyext level. or possibly a subset like PEP 384? That's currently not very interesting since there are basically no C extensions around (generated or hand written) that restrict themselves to that API. Supporting it in Cython would mean that we have to rewrite huge parts of the generated C code. It's not even clear to me yet that we *can* implement all of Cython's features based on PEP 384. For example, fast indexing into lists and tuples is basically a no-no in the restricted C-API. There are tons of rather unexpected restrictions like this. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] PyCon-DE wrap-up by Kay Hayen
On 10 October 2011 09:38, Stefan Behnel wrote: > mark florisson, 09.10.2011 19:57: >> >> On 9 October 2011 18:35, Stefan Behnel wrote: >>> >>> One of the impressions I took out of the technical discussions with Kay >>> is >>> that there isn't really a good reason why Cython should refuse to >>> duplicate >>> some of the inner mechanics of CPython for optimisation purposes. Nuitka >>> appears to be somewhat more aggressive here, partly because Kay doesn't >>> currently care all that much about portability (e.g. to Python 3). >> >> Interesting. What kind of (significant) optimizations could be made by >> duplicating code? Do you want to duplicate entire functions or do you >> want to inline parts of those? > > I was mainly referring to things like direct access to type/object struct > fields and little things like that. Ah, I see. I suppose that if you do everything through Cython-specific macros it will be easy to change it at any time and it will make it easy to experiment with performance as well. > They can make a difference especially in > loops, compared to calling into a generic C-API function. For example, we > could have our own interned implementation of PyDict_Next(). I'm not very > impressed by the performance of that C-API function - repeated calls to > GetItem can be faster than looping over a dict with PyDict_Next()! > > That being said, I wasn't referring to any specific changes. It was more of > a general remark about the invisible line that we currently draw in Cython. > > >> I actually think we should not get too tied to CPython, e.g. what if >> PyPy gets a CPython compatible API > > It already implements a part of the C-API: > > http://morepypy.blogspot.com/2010/04/using-cpython-extension-modules-with.html > > However, if we really want to support it at that level, there's likely more > to do than just removing low-level optimisations. And that would take the > normal route that we always use: macros and conditionally compiled inline > functions. The mere fact that we try to support different targets doesn't > mean that we should stop optimising for specific targets. The same is true > for different versions of CPython, where we often use better optimisations > in newer releases, without sacrificing backwards compatibility. > > Personally, I think that supporting PyPy at the Python level is a lot more > interesting, although it may be easier to get it working at the cpyext > level. > Yeah it's certainly interesting. It might be hard to support things like cython.parallel and efficient buffer access though. I think releasing the GIL might not be very easy either, although perhaps that could be circumvented by factoring the entire nogil block out into a C function which you call with ctypes. >> or possibly a subset like PEP 384? > > That's currently not very interesting since there are basically no C > extensions around (generated or hand written) that restrict themselves to > that API. Supporting it in Cython would mean that we have to rewrite huge > parts of the generated C code. It's not even clear to me yet that we *can* > implement all of Cython's features based on PEP 384. For example, fast > indexing into lists and tuples is basically a no-no in the restricted C-API. > There are tons of rather unexpected restrictions like this. > > Stefan > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] PyCon-DE wrap-up by Kay Hayen
Thanks for the update and link. Sounds like PyCon-DE went well. On Mon, Oct 10, 2011 at 1:38 AM, Stefan Behnel wrote: > mark florisson, 09.10.2011 19:57: >> >> On 9 October 2011 18:35, Stefan Behnel wrote: >>> >>> One of the impressions I took out of the technical discussions with Kay >>> is >>> that there isn't really a good reason why Cython should refuse to >>> duplicate >>> some of the inner mechanics of CPython for optimisation purposes. Nuitka >>> appears to be somewhat more aggressive here, partly because Kay doesn't >>> currently care all that much about portability (e.g. to Python 3). >> >> Interesting. What kind of (significant) optimizations could be made by >> duplicating code? Do you want to duplicate entire functions or do you >> want to inline parts of those? > > I was mainly referring to things like direct access to type/object struct > fields and little things like that. They can make a difference especially in > loops, compared to calling into a generic C-API function. For example, we > could have our own interned implementation of PyDict_Next(). I'm not very > impressed by the performance of that C-API function - repeated calls to > GetItem can be faster than looping over a dict with PyDict_Next()! > > That being said, I wasn't referring to any specific changes. It was more of > a general remark about the invisible line that we currently draw in Cython. CPython, especially the internals, is a slow enough moving target that I'm not too concerned about reaching into the internals if there is a clear benefit. If we're flexible enough to support 2.x and 3.x, I think we can handle 3.(x+1) when it comes. >> I actually think we should not get too tied to CPython, e.g. what if >> PyPy gets a CPython compatible API > > It already implements a part of the C-API: > > http://morepypy.blogspot.com/2010/04/using-cpython-extension-modules-with.html > > However, if we really want to support it at that level, there's likely more > to do than just removing low-level optimisations. And that would take the > normal route that we always use: macros and conditionally compiled inline > functions. The mere fact that we try to support different targets doesn't > mean that we should stop optimising for specific targets. +1 > The same is true > for different versions of CPython, where we often use better optimisations > in newer releases, without sacrificing backwards compatibility. > > Personally, I think that supporting PyPy at the Python level is a lot more > interesting, although it may be easier to get it working at the cpyext > level. > > >> or possibly a subset like PEP 384? > > That's currently not very interesting since there are basically no C > extensions around (generated or hand written) that restrict themselves to > that API. Supporting it in Cython would mean that we have to rewrite huge > parts of the generated C code. It's not even clear to me yet that we *can* > implement all of Cython's features based on PEP 384. For example, fast > indexing into lists and tuples is basically a no-no in the restricted C-API. > There are tons of rather unexpected restrictions like this. I agree, PEP 384 is a nice idea, but it seems to be a rather lot of work for an unclear/small benefit (compared to other stuff we could be doing.) - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
