Transonic Vision: unifying Python-Numpy accelerators

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Transonic Vision: unifying Python-Numpy accelerators

PIERRE AUGIER
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, France                tel:+33.4.56.52.86.16
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Transonic Vision: unifying Python-Numpy accelerators

PIERRE AUGIER
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 <[hidden email]>
> To: [hidden email]
> Subject: [Numpy-discussion] Transonic Vision: unifying Python-Numpy
> accelerators
> Message-ID:
> <[hidden email]>
>
> 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, France                tel:+33.4.56.52.86.16
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Transonic Vision: unifying Python-Numpy accelerators

ralfgommers


On Mon, Nov 4, 2019 at 4:54 PM PIERRE AUGIER <[hidden email]> 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 <[hidden email]>
> To: [hidden email]
> Subject: [Numpy-discussion] Transonic Vision: unifying Python-Numpy
>       accelerators
> Message-ID:
>       <[hidden email]>
>       
> 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, France                tel:+33.4.56.52.86.16
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Transonic Vision: unifying Python-Numpy accelerators

PIERRE AUGIER
In reply to this post by PIERRE AUGIER

> Date: Wed, 6 Nov 2019 23:49:08 -0500
> From: Ralf Gommers <[hidden email]>
> To: Discussion of Numerical Python <[hidden email]>
> Subject: Re: [Numpy-discussion] Transonic Vision: unifying
> Python-Numpy accelerators
> Message-ID:
> <CABL7CQhr6ps25Yrp_pAF8vWVLS3_2=[hidden email]>
> Content-Type: text/plain; charset="utf-8"
>
> On Mon, Nov 4, 2019 at 4:54 PM PIERRE AUGIER <
> [hidden email]> 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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Transonic Vision: unifying Python-Numpy accelerators

ralfgommers


On Tue, Nov 12, 2019 at 1:09 PM PIERRE AUGIER <[hidden email]> wrote:

> Date: Wed, 6 Nov 2019 23:49:08 -0500
> From: Ralf Gommers <[hidden email]>
> To: Discussion of Numerical Python <[hidden email]>
> Subject: Re: [Numpy-discussion] Transonic Vision: unifying
>       Python-Numpy accelerators
> Message-ID:
>       <CABL7CQhr6ps25Yrp_pAF8vWVLS3_2=[hidden email]>
> Content-Type: text/plain; charset="utf-8"
>
> On Mon, Nov 4, 2019 at 4:54 PM PIERRE AUGIER <
> [hidden email]> 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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion