Re: [Numpy-discussion] Transonic Vision: unifying Python-Numpy accelerators
On Tue, Nov 12, 2019 at 1:09 PM PIERRE AUGIER < pierre.aug...@univ-grenoble-alpes.fr> wrote: > > > Date: Wed, 6 Nov 2019 23:49:08 -0500 > > From: Ralf Gommers > > To: Discussion of Numerical Python > > Subject: Re: [Numpy-discussion] Transonic Vision: unifying > > Python-Numpy accelerators > > Message-ID: > >mw4bcoxb0h1dvu9aj...@mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > On Mon, Nov 4, 2019 at 4:54 PM PIERRE AUGIER < > > pierre.aug...@univ-grenoble-alpes.fr> wrote: > > > >> Dear Python-Numpy community, > >> > >> Transonic is a pure Python package to easily accelerate modern > >> Python-Numpy code with different accelerators (currently Cython, Pythran > >> and Numba). > >> > >> I'm trying to get some funding for this project. The related work would > >> benefit in particular to Cython, Numba, Pythran and Xtensor. > >> > >> To obtain this funding, we really need some feedback from some people > >> knowing the subject of performance with Python-Numpy code. > >> > >> That's one of the reason why we wrote this long and serious text on > >> Transonic Vision: http://tiny.cc/transonic-vision. We describe some > >> issues (perf for numerical kernels, incompatible accelerators, community > >> split between experts and simple users, ...) and possible improvements. > >> > > > > Thanks Pierre, that's a very interesting vision paper. > > Thanks Ralf for this kind and interesting reply! > > > > > In case you haven't seen it, there was a discussion on the pandas-dev > > mailing list a couple of weeks ago about adopting Numba as a dependency > > (and issues with that). > > > > Your comment on my assessment from 1.5 years ago being a little unfair to > > Pythran may be true - not sure it was at the time, but Pythran seems to > > mature nicely. > > > > The ability to switch between just-in-time and ahead-of-time compilation > is > > nice. One thing I noticed is that this actual switching is not completely > > fluent: the jit and boost decorators have different signatures, and > there's > > no way to globally switch behavior (say with an env var, as for backend > > selection). > > Yes, it seems evident now but I forgot to update the jit decorators when I > was working on the boost decorator. > My first "targets" for Transonic are packages for which the ahead-of-time > mode seems more adapted. > > This incompatibility between the 2 main decorators used in Transonic will > soon be fixed! > > Regarding the way to globally switch behavior, I'll open a dedicated issue. > > >> Help would be very much appreciated. > >> > > > > I'd be interested to help think about adoption and/or funding. > > > > Cheers, > > Ralf > > > > As you've seen with the jit/boost incompatibility, I guess API design > would be better if people knowing the subject could be included in some > discussions. > > For example, I had to design the Python API for type declaration of arrays > (see > https://transonic.readthedocs.io/en/latest/generated/transonic.typing.html) > since I didn't find anything adapted. My implementation is not great > neither since types in transonic.typing and in `typing` are right now not > compatible ! (However, it won't be difficult to fix that) > > Another API design that needs to be thought is about user-defined types in > Transonic. This is for future because Pythran does not currently support > that, but I think we will have to be able to support kind of dataclass, > something like the equivalent of C struct (corresponding to Cython `cdef > class` and Numba `jitclass`). > > A more theoretical subject that would be interesting to investigate is > about the subset of Python-Numpy that can and should be implemented by > accelerators. This is indeed interesting, I've been thinking about this a lot and have a very rough first cut at what should be included ( https://github.com/Quansight-Labs/rnumpy). That should be redone next year with a better basis for decision-making of what should and should not be in it. For example, I think a function having different branches with different > types for the returned objects depending of runtime values cannot be > rewritten as efficient modern C++. > Agreed. That's anyway due to sub-optimal design decisions long ago in most cases. Cheers, Ralf > If you know people potentially interested to discuss about these subjects, > please tell me. > > Cheers, > Pierre > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Transonic Vision: unifying Python-Numpy accelerators
> Date: Wed, 6 Nov 2019 23:49:08 -0500 > From: Ralf Gommers > To: Discussion of Numerical Python > Subject: Re: [Numpy-discussion] Transonic Vision: unifying > Python-Numpy accelerators > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > On Mon, Nov 4, 2019 at 4:54 PM PIERRE AUGIER < > pierre.aug...@univ-grenoble-alpes.fr> wrote: > >> Dear Python-Numpy community, >> >> Transonic is a pure Python package to easily accelerate modern >> Python-Numpy code with different accelerators (currently Cython, Pythran >> and Numba). >> >> I'm trying to get some funding for this project. The related work would >> benefit in particular to Cython, Numba, Pythran and Xtensor. >> >> To obtain this funding, we really need some feedback from some people >> knowing the subject of performance with Python-Numpy code. >> >> That's one of the reason why we wrote this long and serious text on >> Transonic Vision: http://tiny.cc/transonic-vision. We describe some >> issues (perf for numerical kernels, incompatible accelerators, community >> split between experts and simple users, ...) and possible improvements. >> > > Thanks Pierre, that's a very interesting vision paper. Thanks Ralf for this kind and interesting reply! > > In case you haven't seen it, there was a discussion on the pandas-dev > mailing list a couple of weeks ago about adopting Numba as a dependency > (and issues with that). > > Your comment on my assessment from 1.5 years ago being a little unfair to > Pythran may be true - not sure it was at the time, but Pythran seems to > mature nicely. > > The ability to switch between just-in-time and ahead-of-time compilation is > nice. One thing I noticed is that this actual switching is not completely > fluent: the jit and boost decorators have different signatures, and there's > no way to globally switch behavior (say with an env var, as for backend > selection). Yes, it seems evident now but I forgot to update the jit decorators when I was working on the boost decorator. My first "targets" for Transonic are packages for which the ahead-of-time mode seems more adapted. This incompatibility between the 2 main decorators used in Transonic will soon be fixed! Regarding the way to globally switch behavior, I'll open a dedicated issue. >> Help would be very much appreciated. >> > > I'd be interested to help think about adoption and/or funding. > > Cheers, > Ralf > As you've seen with the jit/boost incompatibility, I guess API design would be better if people knowing the subject could be included in some discussions. For example, I had to design the Python API for type declaration of arrays (see https://transonic.readthedocs.io/en/latest/generated/transonic.typing.html) since I didn't find anything adapted. My implementation is not great neither since types in transonic.typing and in `typing` are right now not compatible ! (However, it won't be difficult to fix that) Another API design that needs to be thought is about user-defined types in Transonic. This is for future because Pythran does not currently support that, but I think we will have to be able to support kind of dataclass, something like the equivalent of C struct (corresponding to Cython `cdef class` and Numba `jitclass`). A more theoretical subject that would be interesting to investigate is about the subset of Python-Numpy that can and should be implemented by accelerators. For example, I think a function having different branches with different types for the returned objects depending of runtime values cannot be rewritten as efficient modern C++. If you know people potentially interested to discuss about these subjects, please tell me. Cheers, Pierre ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Transonic Vision: unifying Python-Numpy accelerators
On Mon, Nov 4, 2019 at 4:54 PM PIERRE AUGIER < pierre.aug...@univ-grenoble-alpes.fr> wrote: > Dear Python-Numpy community, > > Transonic is a pure Python package to easily accelerate modern > Python-Numpy code with different accelerators (currently Cython, Pythran > and Numba). > > I'm trying to get some funding for this project. The related work would > benefit in particular to Cython, Numba, Pythran and Xtensor. > > To obtain this funding, we really need some feedback from some people > knowing the subject of performance with Python-Numpy code. > > That's one of the reason why we wrote this long and serious text on > Transonic Vision: http://tiny.cc/transonic-vision. We describe some > issues (perf for numerical kernels, incompatible accelerators, community > split between experts and simple users, ...) and possible improvements. > Thanks Pierre, that's a very interesting vision paper. In case you haven't seen it, there was a discussion on the pandas-dev mailing list a couple of weeks ago about adopting Numba as a dependency (and issues with that). Your comment on my assessment from 1.5 years ago being a little unfair to Pythran may be true - not sure it was at the time, but Pythran seems to mature nicely. The ability to switch between just-in-time and ahead-of-time compilation is nice. One thing I noticed is that this actual switching is not completely fluent: the jit and boost decorators have different signatures, and there's no way to globally switch behavior (say with an env var, as for backend selection). > Help would be very much appreciated. > I'd be interested to help think about adoption and/or funding. Cheers, Ralf > > Now a coding riddle: > > import numpy as np > from transonic import jit > > @jit(native=True, xsimd=True) > def fxfy(ft, fn, theta): > sin_theta = np.sin(theta) > cos_theta = np.cos(theta) > fx = cos_theta * ft - sin_theta * fn > fy = sin_theta * ft + cos_theta * fn > return fx, fy > > @jit(native=True, xsimd=True) > def fxfy_loops(ft, fn, theta): > n0 = theta.size > fx = np.empty_like(ft) > fy = np.empty_like(fn) > for index in range(n0): > sin_theta = np.sin(theta[index]) > cos_theta = np.cos(theta[index]) > fx[index] = cos_theta * ft[index] - sin_theta * fn[index] > fy[index] = sin_theta * ft[index] + cos_theta * fn[index] > return fx, fy > > How can be compared the performances of these functions with pure Numpy, > Numba and Pythran ? > > You can find out the answer in our note http://tiny.cc/transonic-vision > :-) > > Pierre > > > Message: 1 > > Date: Thu, 31 Oct 2019 21:16:06 +0100 (CET) > > From: PIERRE AUGIER > > To: numpy-discussion@python.org > > Subject: [Numpy-discussion] Transonic Vision: unifying Python-Numpy > > accelerators > > Message-ID: > > < > 1080118635.5930814.1572552966711.javamail.zim...@univ-grenoble-alpes.fr> > > > > Content-Type: text/plain; charset=utf-8 > > > > Dear Python-Numpy community, > > > > Few years ago I started to use a lot Python and Numpy for science. I'd > like to > > thanks all people who contribute to this fantastic community. > > > > I used a lot Cython, Pythran and Numba and for the FluidDyn project, we > created > > Transonic, a pure Python package to easily accelerate modern > Python-Numpy code > > with different accelerators. We wrote a long and serious text to explain > why we > > think Transonic could have a positive impact on the scientific Python > > ecosystem. > > > > Here it is: http://tiny.cc/transonic-vision > > > > Feedback and discussions would be greatly appreciated! > > > > Pierre > > > > -- > > Pierre Augier - CR CNRS http://www.legi.grenoble-inp.fr > > LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels > > BP53, 38041 Grenoble Cedex, Francetel:+33.4.56.52.86.16 > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Transonic Vision: unifying Python-Numpy accelerators
Dear Python-Numpy community, Transonic is a pure Python package to easily accelerate modern Python-Numpy code with different accelerators (currently Cython, Pythran and Numba). I'm trying to get some funding for this project. The related work would benefit in particular to Cython, Numba, Pythran and Xtensor. To obtain this funding, we really need some feedback from some people knowing the subject of performance with Python-Numpy code. That's one of the reason why we wrote this long and serious text on Transonic Vision: http://tiny.cc/transonic-vision. We describe some issues (perf for numerical kernels, incompatible accelerators, community split between experts and simple users, ...) and possible improvements. Help would be very much appreciated. Now a coding riddle: import numpy as np from transonic import jit @jit(native=True, xsimd=True) def fxfy(ft, fn, theta): sin_theta = np.sin(theta) cos_theta = np.cos(theta) fx = cos_theta * ft - sin_theta * fn fy = sin_theta * ft + cos_theta * fn return fx, fy @jit(native=True, xsimd=True) def fxfy_loops(ft, fn, theta): n0 = theta.size fx = np.empty_like(ft) fy = np.empty_like(fn) for index in range(n0): sin_theta = np.sin(theta[index]) cos_theta = np.cos(theta[index]) fx[index] = cos_theta * ft[index] - sin_theta * fn[index] fy[index] = sin_theta * ft[index] + cos_theta * fn[index] return fx, fy How can be compared the performances of these functions with pure Numpy, Numba and Pythran ? You can find out the answer in our note http://tiny.cc/transonic-vision :-) Pierre > Message: 1 > Date: Thu, 31 Oct 2019 21:16:06 +0100 (CET) > From: PIERRE AUGIER > To: numpy-discussion@python.org > Subject: [Numpy-discussion] Transonic Vision: unifying Python-Numpy > accelerators > Message-ID: > > <1080118635.5930814.1572552966711.javamail.zim...@univ-grenoble-alpes.fr> > > Content-Type: text/plain; charset=utf-8 > > Dear Python-Numpy community, > > Few years ago I started to use a lot Python and Numpy for science. I'd like to > thanks all people who contribute to this fantastic community. > > I used a lot Cython, Pythran and Numba and for the FluidDyn project, we > created > Transonic, a pure Python package to easily accelerate modern Python-Numpy code > with different accelerators. We wrote a long and serious text to explain why > we > think Transonic could have a positive impact on the scientific Python > ecosystem. > > Here it is: http://tiny.cc/transonic-vision > > Feedback and discussions would be greatly appreciated! > > Pierre > > -- > Pierre Augier - CR CNRS http://www.legi.grenoble-inp.fr > LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels > BP53, 38041 Grenoble Cedex, Francetel:+33.4.56.52.86.16 ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Transonic Vision: unifying Python-Numpy accelerators
Dear Python-Numpy community, Few years ago I started to use a lot Python and Numpy for science. I'd like to thanks all people who contribute to this fantastic community. I used a lot Cython, Pythran and Numba and for the FluidDyn project, we created Transonic, a pure Python package to easily accelerate modern Python-Numpy code with different accelerators. We wrote a long and serious text to explain why we think Transonic could have a positive impact on the scientific Python ecosystem. Here it is: http://tiny.cc/transonic-vision Feedback and discussions would be greatly appreciated! Pierre -- Pierre Augier - CR CNRS http://www.legi.grenoble-inp.fr LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels BP53, 38041 Grenoble Cedex, Francetel:+33.4.56.52.86.16 ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
