> Date: Wed, 6 Nov 2019 23:49:08 -0500 > From: Ralf Gommers <ralf.gomm...@gmail.com> > To: Discussion of Numerical Python <numpy-discussion@python.org> > Subject: Re: [Numpy-discussion] Transonic Vision: unifying > Python-Numpy accelerators > Message-ID: > <CABL7CQhr6ps25Yrp_pAF8vWVLS3_2=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. 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
