On Tue, Nov 12, 2019 at 1:09 PM PIERRE AUGIER < pierre.augier@univ-grenoble-alpes.fr> wrote:

...

Date: Wed, 6 Nov 2019 23:49:08 -0500 From: Ralf Gommers <ralf.gommers@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= Mw4bCOXb0H1dvU9AjTMw@mail.gmail.com> Content-Type: text/plain; charset="utf-8"

On Mon, Nov 4, 2019 at 4:54 PM PIERRE AUGIER < pierre.augier@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

...

nice. One thing I noticed is that this actual switching is not completely fluent: the jit and boost decorators have different signatures, and

is 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

On Tue, Nov 12, 2019 at 1:09 PM PIERRE AUGIER < pierre.augier@univ-grenoble-alpes.fr> wrote:

...

Date: Wed, 6 Nov 2019 23:49:08 -0500 From: Ralf Gommers <ralf.gommers@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= Mw4bCOXb0H1dvU9AjTMw@mail.gmail.com> Content-Type: text/plain; charset="utf-8"

On Mon, Nov 4, 2019 at 4:54 PM PIERRE AUGIER < pierre.augier@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

...

nice. One thing I noticed is that this actual switching is not completely fluent: the jit and boost decorators have different signatures, and

is 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