Using Pythran to compile some of the scipy internals
Hi Scipy-dev, = Context I've started the experiment of compiling some of the scipy kernels with the Pythran[0] compiler. The approach was basically to pick some easy .pyx file, turn them back to high-level Python + Numpy files then processing them with Pythran. This results in easier to maintain, Python-compatible files that run at the same speed as their Cython alternative up to 10 times faster depending on the kernels and whether SIMD instructions are activated or not (I did not play with parallelization in that experiment). This required a few improvement to Pythran, but not that much, see https://github.com/serge-sans-paille/pythran/pull/770 for the associated PR on pythran, which includes the following scipy kernels: hausdorff.py max_len_seq_inner.py solve_toeplitz.py spectral.py = Why bother? According to that first round of experiments, using Pythran can bring extra speed improvements while remaining at a higher level than Cython. Both points looks like an improvement to me. = Cost? This adds an extra dependency on Pythran, which uses C++ as backend. This increases the failure surface. Although alive since 2012 and being tested a lot [1] on Linux (but scarcely on Windows), its is obviously less mature than cython = Alternatives There is an experimental Pythran mode in cython[2] that uses Pythran as a backend for numpy operations. Unfortunately it is still at early stages and cannot translate calls to ``np.roll`` or ``np.sum(a[i,:] - b[j, :])`` while Pythran supports it. Instead of translating Cython files, I could also focus on some pure-python functions. I tested Pythran on the rosenbrock function and I get good speedup (from 1.5x to 4x depending on vectorization being enabled or not) there too. So yeah, that's a rather long introduction to probe the interest here around that idea :-) Best, Serge PS: I started https://github.com/scipy/scipy/pull/8306 meanwhile, but let's discuss here first :-) [0] https://github.com/serge-sans-paille/pythran [1] https://travis-ci.org/serge-sans-paille/pythran/builds/330052310 [2] http://cython.readthedocs.io/en/latest/src/userguide/numpy_pythran.html
On Sat, Jan 20, 2018 at 11:10 PM, Serge Guelton <serge.guelton@telecom- bretagne.eu> wrote:
Hi Scipy-dev,
= Context
I've started the experiment of compiling some of the scipy kernels with the Pythran[0] compiler.
The approach was basically to pick some easy .pyx file, turn them back to high-level Python + Numpy files then processing them with Pythran. This results in easier to maintain, Python-compatible files that run at the same speed as their Cython alternative up to 10 times faster depending on the kernels and whether SIMD instructions are activated or not (I did not play with parallelization in that experiment).
This required a few improvement to Pythran, but not that much, see
https://github.com/serge-sans-paille/pythran/pull/770
for the associated PR on pythran, which includes the following scipy kernels:
hausdorff.py max_len_seq_inner.py solve_toeplitz.py spectral.py
= Why bother?
According to that first round of experiments, using Pythran can bring extra speed improvements while remaining at a higher level than Cython. Both points looks like an improvement to me.
Another potential benefit is to decrease the size of the binary distribution of SciPy. Cython extensions are quite expensive in this respect. Do you have an idea of how Pythran compares? Both in case of only float64 inputs, and with templated inputs? A good example of the latter is scipy.ndimage.label, which is a straightforward function that ends up being a 700kb .so
= Cost?
This adds an extra dependency on Pythran, which uses C++ as backend.
Only a build-time dependency. That's not my major worry from the maintenance point of view.
This increases the failure surface. Although alive since 2012 and being tested a lot [1] on Linux (but scarcely on Windows), its is obviously less mature than cython
This is a worry. We need Windows, Linux, macOS (officially supported, also the 32-bit flavors) as well as less commonly used Unix/BSD-like platforms. I guess Windows needs separate testing, both with gcc and MSVC. But for all other platforms, can you say something about portability based on the kind of C++ Pythran generates?
= Alternatives
There is an experimental Pythran mode in cython[2] that uses Pythran as a backend for numpy operations. Unfortunately it is still at early stages and cannot translate calls to ``np.roll`` or ``np.sum(a[i,:] - b[j, :])`` while Pythran supports it.
Instead of translating Cython files, I could also focus on some pure-python functions. I tested Pythran on the rosenbrock function and I get good speedup (from 1.5x to 4x depending on vectorization being enabled or not) there too.
So yeah, that's a rather long introduction to probe the interest here around that idea :-)
Interest in general, but there's a long way to go - our requirements are pretty demanding. I have seen some comparisons between Cython, Pythran and Numba in terms of performance and ease of use, but never a comprehensive comparison from the point of view of library authors. I know Travis O. has an interest in seeing Numba being adopted more widely, which will also need such a comparison. It should cover at least: - portability - performance - maturity - maintenance status (active devs, how quick do bugs get fixed after a release with an issue) - ease of use (@jit vs. Pythran comments vs. translate to .pyx syntax) - size of generated binaries - templating support for multiple dtypes - debugging and optimization experience/tools Is anyone aware of such a comparison? Or interested in putting it together? Cheers, Ralf
Best, Serge
PS: I started https://github.com/scipy/scipy/pull/8306 meanwhile, but let's discuss here first :-)
[0] https://github.com/serge-sans-paille/pythran [1] https://travis-ci.org/serge-sans-paille/pythran/builds/330052310 [2] http://cython.readthedocs.io/en/latest/src/userguide/numpy_p ythran.html _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
Another potential benefit is to decrease the size of the binary distribution of SciPy. Cython extensions are quite expensive in this respect. Do you have an idea of how Pythran compares? Both in case of only float64 inputs, and with templated inputs? A good example of the latter is scipy.ndimage.label, which is a straightforward function that ends up being a 700kb .so
Thanks for pointing out this aspect. There's still room for improvement here, but with current pythran's master, and same compilation flags, the cython implementation of `max_len_seq_inner` takes ~700kb while pythran's version takes ~200kb. I'm going to investigate that a bet more though, and probably post the results in this thread later on.
This adds an extra dependency on Pythran, which uses C++ as backend.
Only a build-time dependency. That's not my major worry from the maintenance point of view.
And a dependency to libstc++ too.
This increases the failure surface. Although alive since 2012 and being tested a lot [1] on Linux (but scarcely on Windows), its is obviously less mature than cython
This is a worry. We need Windows, Linux, macOS (officially supported, also the 32-bit flavors) as well as less commonly used Unix/BSD-like platforms.
I guess Windows needs separate testing, both with gcc and MSVC. But for all other platforms, can you say something about portability based on the kind of C++ Pythran generates?
Portability on OSX never required extra work, it's just less tested than the Linux version. There was some C++11 support issue with MSVC compiler back when I tried, but that was some 2 years ago. I'll try again.
= Alternatives
There is an experimental Pythran mode in cython[2] that uses Pythran as a backend for numpy operations. Unfortunately it is still at early stages and cannot translate calls to ``np.roll`` or ``np.sum(a[i,:] - b[j, :])`` while Pythran supports it.
Instead of translating Cython files, I could also focus on some pure-python functions. I tested Pythran on the rosenbrock function and I get good speedup (from 1.5x to 4x depending on vectorization being enabled or not) there too.
So yeah, that's a rather long introduction to probe the interest here around that idea :-)
Interest in general, but there's a long way to go - our requirements are pretty demanding. I have seen some comparisons between Cython, Pythran and Numba in terms of performance and ease of use, but never a comprehensive comparison from the point of view of library authors. I know Travis O. has an interest in seeing Numba being adopted more widely, which will also need such a comparison. It should cover at least:
- portability - performance - maturity - maintenance status (active devs, how quick do bugs get fixed after a release with an issue) - ease of use (@jit vs. Pythran comments vs. translate to .pyx syntax) - size of generated binaries - templating support for multiple dtypes - debugging and optimization experience/tools
Independently of the potential inclusion of Pythran in scipy, those are very valuable points. I'm 100% biased but would say that community and debugging are two weak points of Pythran, esp. when compared to Cython. ++ Serge
On Mon, Jan 22, 2018 at 03:28:40PM +0100, Serge Guelton wrote:
Another potential benefit is to decrease the size of the binary distribution of SciPy. Cython extensions are quite expensive in this respect. Do you have an idea of how Pythran compares? Both in case of only float64 inputs, and with templated inputs? A good example of the latter is scipy.ndimage.label, which is a straightforward function that ends up being a 700kb .so
Thanks for pointing out this aspect. There's still room for improvement here, but with current pythran's master, and same compilation flags, the cython implementation of `max_len_seq_inner` takes ~700kb while pythran's version takes ~200kb.
I'm going to investigate that a bet more though, and probably post the results in this thread later on.
Hey scip-dev, finally the result of some dev + thoughts on Pythran-generated code: http://serge-sans-paille.github.io/pythran-stories/shrinking-pythran-generat... I'll move on to Windows support now :-)
On Mon, Jan 29, 2018 at 12:34:02PM +0100, serge guelton wrote:
On Mon, Jan 22, 2018 at 03:28:40PM +0100, Serge Guelton wrote:
Another potential benefit is to decrease the size of the binary distribution of SciPy. Cython extensions are quite expensive in this respect. Do you have an idea of how Pythran compares? Both in case of only float64 inputs, and with templated inputs? A good example of the latter is scipy.ndimage.label, which is a straightforward function that ends up being a 700kb .so
Thanks for pointing out this aspect. There's still room for improvement here, but with current pythran's master, and same compilation flags, the cython implementation of `max_len_seq_inner` takes ~700kb while pythran's version takes ~200kb.
I'm going to investigate that a bet more though, and probably post the results in this thread later on.
Hey scip-dev, finally the result of some dev + thoughts on Pythran-generated code:
http://serge-sans-paille.github.io/pythran-stories/shrinking-pythran-generat...
I'll move on to Windows support now :-)
Just to make sure: which toolchain is used to build scipy on windows: mingw or msvc? What's the default build environment? WinPython or the official Python binaries from Python.org?
msvc is the only supported toolchain to generate wheels that are compatible with the official binary distribution of Python from python.org and therefore the only compiler that can generate wheels suitable for distribution PyPI. For for the Fortran bits the story is more complicated but I guess that should not have any impact on the use pythran.
On Wed, Jan 31, 2018 at 03:33:29PM +0100, Olivier Grisel wrote:
msvc is the only supported toolchain to generate wheels that are compatible with the official binary distribution of Python from python.org and therefore the only compiler that can generate wheels suitable for distribution PyPI.
OK. I have no trouble using the VS2017 toolchain fro python3, I hope I'm not bound to VS2008 (say for Python 2.7)?
For for the Fortran bits the story is more complicated but I guess that should not have any impact on the use pythran.
In spite of the name similarity, you're correct!
2018-01-31 17:49 GMT+01:00 Serge Guelton <serge.guelton@telecom-bretagne.eu> :
msvc is the only supported toolchain to generate wheels that are compatible with the official binary distribution of Python from python.org and
On Wed, Jan 31, 2018 at 03:33:29PM +0100, Olivier Grisel wrote: therefore
the only compiler that can generate wheels suitable for distribution PyPI.
OK. I have no trouble using the VS2017 toolchain fro python3, I hope I'm not bound to VS2008 (say for Python 2.7)?
Unfortunately yes. But I guess Python 2.7 support for new feature releases of scipy will be phased out in 2019 or so, so maybe it's not that a big problem to not provide pythran-based acceleration for Python 2. Beter not waste too much time on Python 2 ;) -- Olivier
It is actually possible to compiler Windows Python 2.7 extension with more modern compilers than VS2008, and it works well. On Wed, Jan 31, 2018 at 5:55 PM, Olivier Grisel <olivier.grisel@ensta.org> wrote:
2018-01-31 17:49 GMT+01:00 Serge Guelton <serge.guelton@telecom- bretagne.eu>:
msvc is the only supported toolchain to generate wheels that are compatible with the official binary distribution of Python from python.org and
On Wed, Jan 31, 2018 at 03:33:29PM +0100, Olivier Grisel wrote: therefore
the only compiler that can generate wheels suitable for distribution PyPI.
OK. I have no trouble using the VS2017 toolchain fro python3, I hope I'm not bound to VS2008 (say for Python 2.7)?
Unfortunately yes. But I guess Python 2.7 support for new feature releases of scipy will be phased out in 2019 or so, so maybe it's not that a big problem to not provide pythran-based acceleration for Python 2. Beter not waste too much time on Python 2 ;)
-- Olivier
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
On 20 January 2018 at 11:10, Serge Guelton <serge.guelton@telecom- bretagne.eu> wrote:
= Cost?
This adds an extra dependency on Pythran, which uses C++ as backend. This increases the failure surface. Although alive since 2012 and being tested a lot [1] on Linux (but scarcely on Windows), its is obviously less mature than cython
I think this is a blocker, but it seems it is on its way to be fixed: "Pythran supports Python *2.7* and also has a beta Python *3* support." scipy has a lot of Cython code, much of it fairly well tested, which can be very useful for testing Pythran itself. A question, does Pythran eliminate the need for storing intermediate results? Like (a*a).sum(axis=1) for a large a, will it store the full a-squared? (If it is, I'd be very sorry I didn't run into it earlier, and very happy I finally did). /David.
On Mon, Jan 22, 2018 at 04:34:32PM +0100, Daπid wrote:
On 20 January 2018 at 11:10, Serge Guelton <serge.guelton@telecom-bretagne.eu> wrote:
= Cost?
This adds an extra dependency on Pythran, which uses C++ as backend. This increases the failure surface. Although alive since 2012 and being tested a lot [1] on Linux (but scarcely on Windows), its is obviously less mature than cython
I think this is a blocker, but it seems it is on its way to be fixed:
"Pythran supports Python 2.7 and also has a beta Python 3 support."
scipy has a lot of Cython code, much of it fairly well tested, which can be very useful for testing Pythran itself.
Yes, I started integrating cython code from scipy into pythran testbed, after converting them back to Python. It did found some bugs in Pythran, so that's great!
A question, does Pythran eliminate the need for storing intermediate results?
Yep, it turns code like a = b + 1 c = a * 2 into c = (b + 1) * 2 It of course also handles interaction with control flow to forward-substitute only if it does not triggers recomputation.
Like (a*a).sum(axis=1) for a large a, will it store the full a-squared? (If it is, I'd be very sorry I didn't run into it earlier, and very happy I finally did).
Yes, it does perfom lazy evaluation.
Hi scipy-dev, here comes the conclusion of my preliminary work on potential integration of Pythran-compiled kernels into SciPy. The benefits from having Pythran as a build dependency for SciPy would be the following: - no extra runtime dependency (only build dependency) - generally smaller binaries (see http://serge-sans-paille.github.io/pythran-stories/shrinking-pythran-generat...) - comparable if not better performances (see https://github.com/serge-sans-paille/scipy-kernels) - close to no maintenance (Pythran input are pure python code, no extra knowledge is required). A direct consequence is that the exit cost is free. (see the diff in https://github.com/scipy/scipy/pull/8306/files) Now there are several few points that could be improved: - Pythran bus factor is 1. The project did get some momentum recently (even being used in production in a few firms!) but it almost totally relies on me. - windows support is only valid for Python3 - not much feedback for performance optimization (unlike Cython annotate mode), user just need to trust the compiler - no binary multi-versioning to support multiple architecture variant (e.g. AVX support) in a single binary, although this last point can be dealt with if needed, at least on Linux. A bold move for scipy would be to use Pythran in a best-effort mode, i.e. use it when it's available and fallback to Cython otherwise. But I understand there is no strong motivation for this move, only small improvements. Still I'd like to thank the community, especially Ralph, for providing guidance and motivation. A 100% sure outcome of this thread is the improvement of Pythran :-) Best, Serge
Thank you for undertaking this study and for developing Pythran. The results look very promising! How does it compare with Numba? Or is that comparison not valid or nonsensical? On Fri, May 11, 2018, 7:46 AM serge guelton < serge.guelton@telecom-bretagne.eu> wrote:
Hi scipy-dev,
here comes the conclusion of my preliminary work on potential integration of Pythran-compiled kernels into SciPy.
The benefits from having Pythran as a build dependency for SciPy would be the following:
- no extra runtime dependency (only build dependency) - generally smaller binaries (see
http://serge-sans-paille.github.io/pythran-stories/shrinking-pythran-generat... ) - comparable if not better performances (see https://github.com/serge-sans-paille/scipy-kernels) - close to no maintenance (Pythran input are pure python code, no extra knowledge is required). A direct consequence is that the exit cost is free. (see the diff in https://github.com/scipy/scipy/pull/8306/files)
Now there are several few points that could be improved:
- Pythran bus factor is 1. The project did get some momentum recently (even being used in production in a few firms!) but it almost totally relies on me.
- windows support is only valid for Python3
- not much feedback for performance optimization (unlike Cython annotate mode), user just need to trust the compiler
- no binary multi-versioning to support multiple architecture variant (e.g. AVX support) in a single binary, although this last point can be dealt with if needed, at least on Linux.
A bold move for scipy would be to use Pythran in a best-effort mode, i.e. use it when it's available and fallback to Cython otherwise. But I understand there is no strong motivation for this move, only small improvements.
Still I'd like to thank the community, especially Ralph, for providing guidance and motivation. A 100% sure outcome of this thread is the improvement of Pythran :-)
Best,
Serge _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
On Fri, May 11, 2018 at 09:18:03AM -0700, Mark Alexander Mikofski wrote:
Thank you for undertaking this study and for developing Pythran. The results look very promising! How does it compare with Numba? Or is that comparison not valid or nonsensical?
My point of view is 100% biased, but here is the best I can say. there's probably someone on this mlist that knows numba better than I do. Still: cython pythran numba compiler type ahead of time ahead of time just in time runtime dep no no yes language extension +++ + (comments) + (decorator) python support very good decent (no class) decent high level dev + +++ ++ native numpy support + (pythran) +++ ++ (improved a lot) performance good good good simd backend-dependent yes (need a flag) decent (llvm) maturity +++ + ++ This is just a summary and the things that matter are actually in the details, but it's difficult to write about them in a general manner. Hope it helps!
I think the Numba column in your sumamry chart is pretty accurate. On Fri, May 11, 2018 at 12:26 PM, Serge Guelton < serge.guelton@telecom-bretagne.eu> wrote:
On Fri, May 11, 2018 at 09:18:03AM -0700, Mark Alexander Mikofski wrote:
Thank you for undertaking this study and for developing Pythran. The results look very promising! How does it compare with Numba? Or is that comparison not valid or nonsensical?
My point of view is 100% biased, but here is the best I can say. there's probably someone on this mlist that knows numba better than I do. Still:
cython pythran numba
compiler type ahead of time ahead of time just in time runtime dep no no yes language extension +++ + (comments) + (decorator) python support very good decent (no class) decent high level dev + +++ ++ native numpy support + (pythran) +++ ++ (improved a lot) performance good good good simd backend-dependent yes (need a flag) decent (llvm) maturity +++ + ++
This is just a summary and the things that matter are actually in the details, but it's difficult to write about them in a general manner. Hope it helps! _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
participants (8)
-
Daπid -
Mark Alexander Mikofski -
Olivier Grisel -
Ralf Gommers -
serge guelton -
Serge Guelton
-
Stanley Seibert -
Sylvain Corlay