10 ms·

For those with Python 2 baselines that aren't (or will never be) ported, PyPy will support version 2 basically forever [0]. PyPy supports a huge number (but no

by xscott 7y ago

For those with Python 2 baselines that aren't (or will never be) ported, PyPy will support version 2 basically forever [0]. PyPy supports a huge number (but not all) of Python packages, including numpy [1]. Moreover, PyPy is significantly faster in many cases [2], and for the numerical types of things I like to write [3], it's amazingly faster. > time pypy mandel.py > pypy.pgm seconds: 0.318101 real 0m0.426s user 0m0.396s sys 0m0.013s > time python2 mandel.py > python2.pgm seconds: 30.141954 real 0m30.156s user 0m30.136s sys 0m0.003s That's just a silly Mandelbrot example, but for numerical algorithms like this PyPy is nearly 100 times faster than Python2, and that includes startup cost for the JIT! I'm not in any way associated with the PyPy project, but I can't help but believe a sane world would've moved from Python to PyPy in the same way everything moved from Brandon Eich's original JavaScript interpreter to the modern JIT ones like V8. [0] https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-support-python2 https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-s... [1] http://packages.pypy.org/ http://packages.pypy.org/ [2] https://speed.pypy.org/ https://speed.pypy.org/ [3] https://godbolt.org/z/J9Xwp6 https://godbolt.org/z/J9Xwp6

dilap 7y ago
Another casualty of python 3?
- xscott 7y ago
  Honestly, I think Python's C API exposing so much of the internals of the implementation is the real problem. You can basically see every pointer in every struct, including tons of things you shouldn't need. Large packages inevitably end up using some unfortunate detail which couples them tightly to CPython, and this makes using those packages with PyPy nearly impossible. The fact that PyPy got so many of those to work as well as they did (numpy stands out) is a testament to their talent and stamina. I believe this is also a huge part of the reason why migrating from CPython version 2 to version 3 was delayed. I've adapted a few small C extension modules to run under both, and using #ifdef for the special cases to support both was unpleasant. So I imagine that any large package which needed to support both through the transition really suffered for it.
  - int_19h 7y ago
    Python 3 has "limited API", which is much better in that regard. https://www.python.org/dev/peps/pep-0384/ https://www.python.org/dev/peps/pep-0384/
deleted 7y ago
[deleted]
RMPR 7y ago
Came here just to say that PyPy is amazing, from my somewhat limited exposure, it fulfilled my use case very well with a speed gain.
talentedcoin 7y ago
This is pretty interesting. Years ago I had a bunch of code that was basically just matrix multiplication with some large-ish matrices, and then taking some eigenvectors/eigenvalues at the end. At the time I found the same thing -- if I decomposed things into simple lists of numbers for vectors and lists of lists PyPy was way faster. I just had the opportunity to brush this code off in Python 3 and run it as-is, and it performs much better than it used to. But I am always curious to hear about these cases. PyPy really is a wonderful project.
joshuamorton 7y ago
Pypy is great, but numpy is even faster (2-3x over your pypy example), and the code is less strange. Here's the mandel function in numpy: def mandel(data: np.ndarray): c = data z = c for j in range(255): z = z**2 + c (from here: https://scipy-lectures.org/intro/numpy/auto_examples/plot_mandelbrot.html https://scipy-lectures.org/intro/numpy/auto_examples/plot_ma...)
- xscott 7y ago
  Yeah, that's the thing with silly examples (like my Mandelbrot program). For real code, I frequently need to write low level loops which aren't easily expressed as parallel operations. If numpy doesn't have it, or if you can't figure out how to parallelize it, you're screwed. Moreover, for some very common things in signal processing, like working with evens/odds or left/right parts of an array, the parallel numpy operation will create lots of temporary arrays and copies. And for what it's worth, your version of mandel should work with PyPy. So you can have your cake and eat it too. EDIT: I should add the reason my code is "strange" is because I wrote it so I could do a one-to-one comparison with other languages which don't have builtin complex numbers. Maybe I should've cleaned that up before posting.
  - joshuamorton 7y ago
    > Moreover, for some very common things in signal processing, like working with evens/odds or left/right parts of an array, the parallel numpy operation will create lots of temporary arrays and copies. iiuc, this shouldn't be correct. given an ndarray A, `A[::2, 1::2]` will provide a (no-copy) view of the even rows/columns of A. Same with A[:len(A)/2] to get only half of A. > And for what it's worth, your version of mandel should work with PyPy. So you can have your cake and eat it too. Indeed, most of the scipy stack works with Pypy, it's great.
    - xscott 7y ago
      As soon as you do any operations (addition, subtraction, etc...) on those views, you're going to get temporary arrays. For instance, your Mandelbrot example doesn't even use views and it creates two temporaries the size of the entire array on each iteration: for j in range(255): t = z**2 # create a new squared array u = t + c # create a new summed array z = u # replace the old array And all of this is ignoring how inconsistent numpy is about when it creates a view and when it creates a copy.
macNchz 7y ago
I saw pretty great results switching a pretty “standard” high traffic Python web app (Flask & uwsgi) over to run on PyPy. We saw about 30% faster response time for HTTP requests, several times the number of tasks/second on the workers, and we were able to scale down the total instances needed. Mostly the typical Python web app libraries just worked, and I spent a couple of days making sure everything was stable, but it was a great success overall.
orangecat 7y ago
I can't help but believe a sane world would've moved from Python to PyPy Yes, and this is my fundamental complaint with the Python 3 transition. It took probably millions of engineer-hours, and the result was better Unicode support and a handful of minor features most of which could have been added to Python 2 just as easily. I suspect most users would gladly have traded those benefits for a 10x performance improvement.
- mehrdadn 7y ago
  I didn't want to reply to the PyPy comment and be negative, but I haven't really gotten speedup from the few times I've tried PyPy. In fact I've generally gotten slowdowns. Definitely not 10x improvements. I'm not sure what the reason might be though, because the rest of the world seems to think differently.
  - ericflo 7y ago
    It's been a while since I used PyPy, but JITs in general warm up over time. If you have hot loops with heavy arithmetic and no branches, that's usually best case scenario for JITs. If you have branchy non-uniform control flow, that's the worse scenario. So it really depends on your usage - you may be paying the JIT overhead costs with little benefit.
    - xscott 7y ago
      Spot on, and the difference between a tracing JIT vs a method JIT can be night and day too.
  - ehsankia 7y ago
    Really depends on the kind of work you're doing. As mentioned above, numerical and looping code will see the most benefit. I used it heavily when doing Project Euler problems, and those would easily see 10-100x speedups, taking some problems from 5-10m run time to seconds.
- xscott 7y ago
  > millions of engineer-hours, and the result was better Unicode support and a handful of minor features Yes, and I wish the better Unicode support had been implemented similarly to how Go does it - one string type, and you use it to hold UTF-8 if needed. In other words, they could've simply deprecated the Python 2.X unicode object and added libraries to extract code points, or grapheme clusters, or perform normalization etc... This seems much simpler and more "Pythonic". I guess everything is 20/20 in hindsight.
takeda 7y ago
The python is the least of issues, you can just keep 2.7.18 and 10 years from now it will still work. The problem is dependencies. Developers of packages couldn't wait until they can drop all the cruft that python 2.7 was required. https://python3statement.org/ https://python3statement.org/ Just do yourself a favor and migrate your codebase, Py3 is much more enjoyable to program in. I feel like all those vocal Python 2 supporters never had a chance to write a new code in Python 3. If you only did 2->3 migration you might hate Python 3, because it doesn't let you run a broken code that Python 2 happily executed, but if you can write Python 3 app from scratch you don't even notice the unicode, text is just text.
- physicsguy 7y ago
  "A broken code that happily executed"? I think that's unfair. There was plenty of code that was out there for 10 years or more that was working completely fine and had to be ported. One of the most frustrating things I had to do was completely rearchitect some legacy binary file reading/writing because of the changes to how Python handled bytes. That code was out there as open source in the wild, stable, and was being widely used, and it basically required a full rewrite underneath the API. One of the most frustrating things was that many packages we used as dependencies took ~5 years to port to Python 3, and then dropped Python 2 support immediately, leaving us with no choice but to use the old version for some time. We'd done a lot of the easy stuff already (2to3 on all files), but lots of the non-trivial things were the interactions with other packages so couldn't be touched until they had themselves got a Python 3 version.
  - toyg 7y ago
    > many packages we used as dependencies took ~5 years to port to Python 3, and then dropped Python 2 support immediately A lot of packages were held back by early criticism of the move and the extended timeframe allowed to 2.x. If 10% of the stop-energy dedicated to shit on 3 would have been put into supporting the effort, things would have gone differently. But most people dragged their feet and this is the result.
olsgaarddk 7y ago
I am interested and would like to learn more. So do you just sudo apt install pypy3 and then pypy3 -m pytest /my/python/app and if things go well you either got a 5-10x speed up or an insufficient test suite?

by xscott 7y ago

dilap 7y ago

Another casualty of python 3?

xscott 7y ago
Honestly, I think Python's C API exposing so much of the internals of the implementation is the real problem. You can basically see every pointer in every struct, including tons of things you shouldn't need. Large packages inevitably end up using some unfortunate detail which couples them tightly to CPython, and this makes using those packages with PyPy nearly impossible. The fact that PyPy got so many of those to work as well as they did (numpy stands out) is a testament to their talent and stamina. I believe this is also a huge part of the reason why migrating from CPython version 2 to version 3 was delayed. I've adapted a few small C extension modules to run under both, and using #ifdef for the special cases to support both was unpleasant. So I imagine that any large package which needed to support both through the transition really suffered for it.
- int_19h 7y ago
  Python 3 has "limited API", which is much better in that regard. https://www.python.org/dev/peps/pep-0384/ https://www.python.org/dev/peps/pep-0384/

deleted 7y ago

[deleted]

RMPR 7y ago

Came here just to say that PyPy is amazing, from my somewhat limited exposure, it fulfilled my use case very well with a speed gain.

talentedcoin 7y ago

This is pretty interesting. Years ago I had a bunch of code that was basically just matrix multiplication with some large-ish matrices, and then taking some eigenvectors/eigenvalues at the end. At the time I found the same thing -- if I decomposed things into simple lists of numbers for vectors and lists of lists PyPy was way faster. I just had the opportunity to brush this code off in Python 3 and run it as-is, and it performs much better than it used to. But I am always curious to hear about these cases. PyPy really is a wonderful project.

joshuamorton 7y ago

Pypy is great, but numpy is even faster (2-3x over your pypy example), and the code is less strange. Here's the mandel function in numpy: def mandel(data: np.ndarray): c = data z = c for j in range(255): z = z**2 + c (from here: https://scipy-lectures.org/intro/numpy/auto_examples/plot_mandelbrot.html https://scipy-lectures.org/intro/numpy/auto_examples/plot_ma...)

xscott 7y ago
Yeah, that's the thing with silly examples (like my Mandelbrot program). For real code, I frequently need to write low level loops which aren't easily expressed as parallel operations. If numpy doesn't have it, or if you can't figure out how to parallelize it, you're screwed. Moreover, for some very common things in signal processing, like working with evens/odds or left/right parts of an array, the parallel numpy operation will create lots of temporary arrays and copies. And for what it's worth, your version of mandel should work with PyPy. So you can have your cake and eat it too. EDIT: I should add the reason my code is "strange" is because I wrote it so I could do a one-to-one comparison with other languages which don't have builtin complex numbers. Maybe I should've cleaned that up before posting.
- joshuamorton 7y ago
  > Moreover, for some very common things in signal processing, like working with evens/odds or left/right parts of an array, the parallel numpy operation will create lots of temporary arrays and copies. iiuc, this shouldn't be correct. given an ndarray A, `A[::2, 1::2]` will provide a (no-copy) view of the even rows/columns of A. Same with A[:len(A)/2] to get only half of A. > And for what it's worth, your version of mandel should work with PyPy. So you can have your cake and eat it too. Indeed, most of the scipy stack works with Pypy, it's great.
  - xscott 7y ago
    As soon as you do any operations (addition, subtraction, etc...) on those views, you're going to get temporary arrays. For instance, your Mandelbrot example doesn't even use views and it creates two temporaries the size of the entire array on each iteration: for j in range(255): t = z**2 # create a new squared array u = t + c # create a new summed array z = u # replace the old array And all of this is ignoring how inconsistent numpy is about when it creates a view and when it creates a copy.

macNchz 7y ago

I saw pretty great results switching a pretty “standard” high traffic Python web app (Flask & uwsgi) over to run on PyPy. We saw about 30% faster response time for HTTP requests, several times the number of tasks/second on the workers, and we were able to scale down the total instances needed. Mostly the typical Python web app libraries just worked, and I spent a couple of days making sure everything was stable, but it was a great success overall.

orangecat 7y ago

I can't help but believe a sane world would've moved from Python to PyPy Yes, and this is my fundamental complaint with the Python 3 transition. It took probably millions of engineer-hours, and the result was better Unicode support and a handful of minor features most of which could have been added to Python 2 just as easily. I suspect most users would gladly have traded those benefits for a 10x performance improvement.

mehrdadn 7y ago
I didn't want to reply to the PyPy comment and be negative, but I haven't really gotten speedup from the few times I've tried PyPy. In fact I've generally gotten slowdowns. Definitely not 10x improvements. I'm not sure what the reason might be though, because the rest of the world seems to think differently.
- ericflo 7y ago
  It's been a while since I used PyPy, but JITs in general warm up over time. If you have hot loops with heavy arithmetic and no branches, that's usually best case scenario for JITs. If you have branchy non-uniform control flow, that's the worse scenario. So it really depends on your usage - you may be paying the JIT overhead costs with little benefit.
  - xscott 7y ago
    Spot on, and the difference between a tracing JIT vs a method JIT can be night and day too.
- ehsankia 7y ago
  Really depends on the kind of work you're doing. As mentioned above, numerical and looping code will see the most benefit. I used it heavily when doing Project Euler problems, and those would easily see 10-100x speedups, taking some problems from 5-10m run time to seconds.
xscott 7y ago
> millions of engineer-hours, and the result was better Unicode support and a handful of minor features Yes, and I wish the better Unicode support had been implemented similarly to how Go does it - one string type, and you use it to hold UTF-8 if needed. In other words, they could've simply deprecated the Python 2.X unicode object and added libraries to extract code points, or grapheme clusters, or perform normalization etc... This seems much simpler and more "Pythonic". I guess everything is 20/20 in hindsight.

takeda 7y ago

The python is the least of issues, you can just keep 2.7.18 and 10 years from now it will still work. The problem is dependencies. Developers of packages couldn't wait until they can drop all the cruft that python 2.7 was required. https://python3statement.org/ https://python3statement.org/ Just do yourself a favor and migrate your codebase, Py3 is much more enjoyable to program in. I feel like all those vocal Python 2 supporters never had a chance to write a new code in Python 3. If you only did 2->3 migration you might hate Python 3, because it doesn't let you run a broken code that Python 2 happily executed, but if you can write Python 3 app from scratch you don't even notice the unicode, text is just text.

physicsguy 7y ago
"A broken code that happily executed"? I think that's unfair. There was plenty of code that was out there for 10 years or more that was working completely fine and had to be ported. One of the most frustrating things I had to do was completely rearchitect some legacy binary file reading/writing because of the changes to how Python handled bytes. That code was out there as open source in the wild, stable, and was being widely used, and it basically required a full rewrite underneath the API. One of the most frustrating things was that many packages we used as dependencies took ~5 years to port to Python 3, and then dropped Python 2 support immediately, leaving us with no choice but to use the old version for some time. We'd done a lot of the easy stuff already (2to3 on all files), but lots of the non-trivial things were the interactions with other packages so couldn't be touched until they had themselves got a Python 3 version.
- toyg 7y ago
  > many packages we used as dependencies took ~5 years to port to Python 3, and then dropped Python 2 support immediately A lot of packages were held back by early criticism of the move and the extended timeframe allowed to 2.x. If 10% of the stop-energy dedicated to shit on 3 would have been put into supporting the effort, things would have gone differently. But most people dragged their feet and this is the result.

olsgaarddk 7y ago

I am interested and would like to learn more. So do you just sudo apt install pypy3 and then pypy3 -m pytest /my/python/app and if things go well you either got a 5-10x speed up or an insufficient test suite?