Running Numba on PyPy

0 views
Skip to first unread message

graham....@embecosm.com

unread,
Jan 19, 2017, 9:49:29 AM1/19/17
to Numba Public Discussion - Public
Hi,

I've recently been working on getting Numba to run on PyPy, with some success; my current branch has 91.5% of Numba tests passing on PyPy, so most things are working. From the set of experiments that I've done, there appears to be a small overhead of using Numba on PyPy compared to CPython - I suspect that this is a bit of cpyext overhead that would mostly be amortised for jitted functions that have a reasonable workload.

A summary of the changes I needed to make and some test results and performance experiments are described in: http://www.embecosm.com/2017/01/19/running-numba-on-pypy/

I'd be interested in feedback on this - in particular, if there are interesting use cases for running Numba on PyPy, and whether the work required to improve the patches would be worthwhile.


Best regards,
Graham.

Stanley Seibert

unread,
Jan 19, 2017, 10:04:24 AM1/19/17
to Numba Public Discussion - Public
Hi Graham,

This is very exciting to see!  I've wondered whether PyPy could use Numba as a final-stage optimizer for numerical code, and your patches would provide the framework for those experiments.  Additionally, we're starting to see a few packages achieve high performance entirely through Python + Numba (for example, the fastparquet project is using Numba for all of its speed critical code), so having Numba work in both CPython and PyPy means that package authors can achieve more portable performance between the two runtimes.

(That said, fastparquet specifically also depends on pandas, so it may not be the best example at the moment, unless pandas also works in PyPy now.)

We're also in the process of upgrading to LLVM 3.9 (with LLVM 4.0 likely coming shortly after its official release).  There should be some major improvements to SIMD code generation in those releases, so it is possible that they will produce more efficient code than PyPy's backend on some numerical functions.  That might also provide a win.

One last question: Any thoughts on what it would take to support the CUDA target as well?  It would be very awesome to have a way to run GPU code from within PyPy.


--
You received this message because you are subscribed to the Google Groups "Numba Public Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to numba-users+unsubscribe@continuum.io.
To post to this group, send email to numba...@continuum.io.
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/numba-users/0535f84c-e4b0-49c0-9eba-b8e0ecaf977b%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Stanley Seibert

unread,
Jan 19, 2017, 10:17:39 AM1/19/17
to Numba Public Discussion - Public
Also, I might not have been clear: we are very interested in a PR to add PyPy support and will put the appropriate testing into our CI system.  :)

Siu Kwan Lam

unread,
Jan 19, 2017, 10:48:53 AM1/19/17
to Numba Public Discussion - Public
Graham,

That is amazing work!   I wonder how much compile-time improvement PyPy is bringing, even though a significant amount of time is inside llvm. Numba is getting more analysis passes before sending to llvm and the llvmlite binding has a lot of string ops.  These are areas that PyPy can really help.



On Thu, Jan 19, 2017 at 9:17 AM Stanley Seibert <stan.s...@continuum.io> wrote:
Also, I might not have been clear: we are very interested in a PR to add PyPy support and will put the appropriate testing into our CI system.  :)
On Thu, Jan 19, 2017 at 9:04 AM, Stanley Seibert <stan.s...@continuum.io> wrote:
Hi Graham,

This is very exciting to see!  I've wondered whether PyPy could use Numba as a final-stage optimizer for numerical code, and your patches would provide the framework for those experiments.  Additionally, we're starting to see a few packages achieve high performance entirely through Python + Numba (for example, the fastparquet project is using Numba for all of its speed critical code), so having Numba work in both CPython and PyPy means that package authors can achieve more portable performance between the two runtimes.

(That said, fastparquet specifically also depends on pandas, so it may not be the best example at the moment, unless pandas also works in PyPy now.)

We're also in the process of upgrading to LLVM 3.9 (with LLVM 4.0 likely coming shortly after its official release).  There should be some major improvements to SIMD code generation in those releases, so it is possible that they will produce more efficient code than PyPy's backend on some numerical functions.  That might also provide a win.

One last question: Any thoughts on what it would take to support the CUDA target as well?  It would be very awesome to have a way to run GPU code from within PyPy.

On Thu, Jan 19, 2017 at 8:28 AM, <graham....@embecosm.com> wrote:
Hi,

I've recently been working on getting Numba to run on PyPy, with some success; my current branch has 91.5% of Numba tests passing on PyPy, so most things are working. From the set of experiments that I've done, there appears to be a small overhead of using Numba on PyPy compared to CPython - I suspect that this is a bit of cpyext overhead that would mostly be amortised for jitted functions that have a reasonable workload.

A summary of the changes I needed to make and some test results and performance experiments are described in: http://www.embecosm.com/2017/01/19/running-numba-on-pypy/

I'd be interested in feedback on this - in particular, if there are interesting use cases for running Numba on PyPy, and whether the work required to improve the patches would be worthwhile.


Best regards,
Graham.

--
You received this message because you are subscribed to the Google Groups "Numba Public Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to numba-users...@continuum.io.

--
You received this message because you are subscribed to the Google Groups "Numba Public Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to numba-users...@continuum.io.

To post to this group, send email to numba...@continuum.io.
--
Siu Kwan Lam
Software Engineer
Continuum Analytics

graham....@embecosm.com

unread,
Jan 19, 2017, 12:37:23 PM1/19/17
to Numba Public Discussion - Public
Hi Stan,

Many thanks for the quick feedback :-)


On Thursday, 19 January 2017 15:04:24 UTC, Stanley Seibert wrote:
Hi Graham,

This is very exciting to see!  I've wondered whether PyPy could use Numba as a final-stage optimizer for numerical code, and your patches would provide the framework for those experiments.

That sounds like an interesting experiment - I don't think I am familiar enough with PyPy to be able to begin any of those experiments, but would be happy to try and provide support for using the patches to do those experiments.
 
  Additionally, we're starting to see a few packages achieve high performance entirely through Python + Numba (for example, the fastparquet project is using Numba for all of its speed critical code), so having Numba work in both CPython and PyPy means that package authors can achieve more portable performance between the two runtimes.

(That said, fastparquet specifically also depends on pandas, so it may not be the best example at the moment, unless pandas also works in PyPy now.)

"pip install pandas" did not seem to work for me (compilation error) in PyPy, so it doesn't trivially work, at least. :-(
 
We're also in the process of upgrading to LLVM 3.9 (with LLVM 4.0 likely coming shortly after its official release).  There should be some major improvements to SIMD code generation in those releases, so it is possible that they will produce more efficient code than PyPy's backend on some numerical functions.  That might also provide a win.

From the limited experiments I have done, I suspect that it might be quite hard to get performance out of PyPy that is as good as Numba's for numerical code (though I observed that the benchmarks I have are possibly not representative of larger numerical workloads, there is quite a big increase in runtime for the PyPy-only variants of the benchmarks).
 
One last question: Any thoughts on what it would take to support the CUDA target as well?  It would be very awesome to have a way to run GPU code from within PyPy.


I'm not aware of what the issues would be - hopefully just a set of small changes to the CUDA driver code... I haven't been able to try it out because I don't have a CUDA GPU at the moment, but it would be worth a try if I had access to a system with a CUDA GPU.
 

Best regards,
Graham.

graham....@embecosm.com

unread,
Jan 19, 2017, 5:32:06 PM1/19/17
to Numba Public Discussion - Public
Hi Stan,


On Thursday, 19 January 2017 15:17:39 UTC, Stanley Seibert wrote:
Also, I might not have been clear: we are very interested in a PR to add PyPy support and will put the appropriate testing into our CI system.  :)



OK - thanks for the clarity :-)

I think for the purposes of trying to integrate the changes back into Numba, I'd like to split up the changes into a few PRs to make it a bit easier to get through everything, with the final PR or two adding appropriate Travis configuration and test skipping when running on PyPy. I think there's quite a danger that I'd never finish a single large patch that contained all the changes necessary in one go :-)

I'll have a look at starting to make some of these patches when I next get a few minutes.

Best regards,
Graham.

Nathaniel Smith

unread,
Jan 19, 2017, 6:20:17 PM1/19/17
to numba...@continuum.io
On Thu, Jan 19, 2017 at 7:04 AM, Stanley Seibert
<stan.s...@continuum.io> wrote:
> (That said, fastparquet specifically also depends on pandas, so it may not
> be the best example at the moment, unless pandas also works in PyPy now.)

My understanding is that pandas-on-pypy is not quite there yet but
Matti's actively working on it and getting close. There may well be a
pypy branch that can run pandas well enough to at least experiment
with fastparquet.

-n

--
Nathaniel J. Smith -- https://vorpus.org

Nathaniel Smith

unread,
Jan 20, 2017, 2:54:26 AM1/20/17
to numba...@continuum.io
From #pypy:

<mattip> njs: fwiw, I am kind of documenting progress with pandas here
<mattip> https://bitbucket.org/pypy/pypy/wiki/cpyext_2_-_cython
<mattip> basically the pandas head (not yet released) + pypy nightly
(not yet released) can import and run
<mattip> but there are issues with recounting semantics and calling
cython's __dealloc__ way too late if at all
<mattip> so we hold on to too much memory

Stanley Seibert

unread,
Jan 20, 2017, 9:50:08 AM1/20/17
to Numba Public Discussion - Public
Antoine informs me that fastparquet also has a small bit of Cython now, but I'm sure that could be worked around if the rest of its dependency stack was available on PyPy.

--
You received this message because you are subscribed to the Google Groups "Numba Public Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to numba-users+unsubscribe@continuum.io.
To post to this group, send email to numba...@continuum.io.
Reply all
Reply to author
Forward
0 new messages