Still no PyPy support

[GoogleCodeExporter]

PyPy still can't build gmpy, any word on this?

Original issue reported on code.google.com by 16sn...@gmail.com on 4 Oct 2012 at 7:26

[GoogleCodeExporter]

The current versions of gmpy (1.x and 2.x) both rely on "internal" CPython 
calls and assume a reference counting memory manager. Even if they can be 
implemented by cpyext (sp??), I think the overhead will be too high. To get the 
performance advantages of PyPy, I think an interface will need to be written in 
either RPython or the new FFI library that is being developed.

I haven't followed PyPy development lately so if I'm wrong, please let me know.

Original comment by casevh on 5 Oct 2012 at 1:46

• Changed state: Accepted
• Added labels: Type-Enhancement, Priority-Low
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

PyPy has added some more support for CPython style C extensions, but I think 
you're right; it should be written in RPython/FFI. 

A total rewrite in RPython/FFI sounds like lots of work. (It could be called 
gmpypy  analogous to numpypy ;) ). If I get time I might try implementing a 
small subset of gmpy

Original comment by 16sn...@gmail.com on 5 Oct 2012 at 2:03

[GoogleCodeExporter]

I'm closing the issue but please let me know if you start to work on gmpypy.

Original comment by casevh on 12 Oct 2012 at 6:12

• Changed state: WontFix

[GoogleCodeExporter]

I found a partial implementation of gmpy using cffi on 
http://bazaar.launchpad.net/~tolot-solar-empire/+junk/gmpy_cffi/.

I've cleaned this up, and plan to add to it, see: 
https://github.com/sn6uv/gmpy_cffi

Since it uses cffi it works with both CPython and PyPy.

The downsides of this approach is that it's currently quite a bit slower than 
gmpy and gmpy2:

In [15]: %timeit gmpy2.mpz(random.randint(-sys.maxint, sys.maxint))
100000 loops, best of 3: 4.04 µs per loop

In [16]: %timeit gmpy.mpz(random.randint(-sys.maxint, sys.maxint))
100000 loops, best of 3: 4 µs per loop

In [17]: %timeit gmpy_cffi.mpz(random.randint(-sys.maxint, sys.maxint))
100000 loops, best of 3: 10.1 µs per loop

In [18]: %timeit random.randint(-sys.maxint, sys.maxint)
100000 loops, best of 3: 3.81 µs per loop

Original comment by 16sn...@gmail.com on 4 Nov 2013 at 11:05

[GoogleCodeExporter]

Thanks for the update. I quickly scanned the code and CFFI definitely makes for 
cleaner code than writing in C. I'll installed PyPy on my system and try it.

Thanks for the update.

Original comment by casevh on 4 Nov 2013 at 3:37

[GoogleCodeExporter]

I was very excited about this. Unfortunately, in its current form, it seems to 
be too slow to be practical. One function I wanted to test in partcular, 
mpz_sqrt, isn't implemented, so I added it:

interface.py.diff         : http://codepad.org/3NfTaRDP
special_functions.py.diff : http://codepad.org/iZAb7QYr
__init__.py.diff          : http://codepad.org/33TFMH1K

And a quick test:

$ pypy -m timeit -s "from math import sqrt" "for i in range(1000): 
int(sqrt(123456789 + i))"
100000 loops, best of 3: 7.59 usec per loop

$ pypy -m timeit -s "from gmpy_cffi import sqrt" "for i in range(1000): 
sqrt(123456789 + i)"
100 loops, best of 3: 3.11 msec per loop

About 400x slower. For this range, arbitrary precision isn't required, but it's 
still considerably slower than a hand-rolled Newton-Raphson, for example: 
http://codepad.org/x0FheYNH

$ pypy -m timeit -s "from my_math import isqrt; from math import sqrt" "for i 
in range(1000): isqrt(123456789 + i)"
10000 loops, best of 3: 108 usec per loop

I don't mean to be a voice of discouragement, or to imply that this approach 
won't work, but something would need mitigate these bottlenecks.

Original comment by mike.try...@gmail.com on 2 Jun 2014 at 4:35

[GoogleCodeExporter]

Hi,

Just so you know, I don't maintain gmpy_cffi. I would report your
change to https://github.com/sn6uv/gmpy_cffi

I looked at PyPy support a long time ago and the only approach that
had sufficiently low overhead was writing the interface directly in
RPython and compiling GMP support directly into PyPy. Due to licensing
differences between GMP (LGPL 3) and PyPy (MIT), I didn't pursue it
any further. (I think PyPy with GMP/MPFR/MPC could only be distributed
in source form, but IANAL, etc.)

There may be improvements to CFFI that will help in the future.

I haven't heard of any plans for PyPy to support PyPy-specific
compiled extension modules.

Case

Original comment by casevh on 2 Jun 2014 at 5:44