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 <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. 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
