12 ms·

PyPy 2.6.0 released

147 points by mattip 11y ago

mattip 11y ago
PyPy 2.6.0 - "Cameo Charm" since PyPy looks best in profile
tiffanyh 11y ago
A few data points and questions: - it appears PyPy performance improvements have begun to plateau [1] - what's not measured is memory consumption in comparision to CPython. I've read anecdotal evidence that indicates PyPy is increase in memory usage [2] - I also have not found a chart that depicts how compatible PyPy is vs CPython. If someone had a chart of this over time, that'd be great. [1] http://speed.pypy.org/ http://speed.pypy.org/ [2] http://stackoverflow.com/questions/29000279/pypy-memory-usage-increasing-over-time http://stackoverflow.com/questions/29000279/pypy-memory-usag...
- deleted 11y ago
  [deleted]
- maheart 11y ago
  > - it appears PyPy performance improvements have begun to plateau [1] It does appear that Pypy's performance is reaching some asymptotic limit, but there's always new avenues to investigate. e.g. The STM branch of Pypy removes the GIL, and allows code to scale nicely across cores[1] [1]http://morepypy.blogspot.ch/2014/07/pypy-stm-first-interesting-release.html http://morepypy.blogspot.ch/2014/07/pypy-stm-first-interesti...
- chrisseaton 11y ago
  I think there are still whole classes of optimisations that PyPy doesn't do yet but could, aren't there? Vectorisation, for example? There's no way they have exhausted all possible compiler optimisation avenues that are known.
- mattip 11y ago
  Performance improvements have been driven by user-reported slowdowns. The more users that report performance problems, the more the entire community profits. There are more performance improvements on the way: STM [1] will do away with the GIL in a transparent way, we have a GSOC underway to teach the JIT to use SIMD coprocessor commands, and hopefully CFFI 1.1 [2] will smooth the corners where there is no escape from C code. Memory use is very application dependent. I cannot improve on the answer given to the question on SO. As far as compatibility goes, PyPy 2.6.0 uses the CPython 2.7.9 stdlib - pure python code is 100% compatible (barring bugs). Packages such as Pillow [3] have made sure they are PyPy friendly even where they use C code. Numpy [4] is still a work-in-progress but much of it already works (we are implementing version 1.9.0 for now). The surface area is huge and very wrinkled, so it will take some time to finish all the corners. Please try it out and let us know if your code doesn't run. [1] http://pypy.org/tmdonate2.html http://pypy.org/tmdonate2.html [2] https://cffi.readthedocs.org https://cffi.readthedocs.org [3] https://python-pillow.github.io https://python-pillow.github.io [4] http://buildbot.pypy.org/numpy-status/latest.html http://buildbot.pypy.org/numpy-status/latest.html
  - joshuapants 11y ago
    > PyPy 2.6.0 uses the CPython 2.7.9 stdlib - pure python code is 100% compatible (barring bugs) Is it possible to use PyPy with py2exe or freeze so that I can distribute a Python application to someone so that they don't have to go and install PyPy to get performance benefits?
    - mwcampbell 11y ago
      I'd like to propose a different approach to that problem, one that also addresses the issue of startup time: a boot image. I got the name from the Avian JVM (https://github.com/ReadyTalk/avian https://github.com/ReadyTalk/avian), but a similar concept can be seen at least as far back as GNU Emacs in the 90s. The idea is that as part of the build process, you load all of a program's code and initial data into memory, then dump the heap. Then at startup, you just have to map the heap back into memory, and possibly fix up pointers if you can't load everything at the same address as before. Of course, you'd have to make sure that none of the objects in the saved heap contain handles to external resources like files. Also, for PyPy, which is JIT-compiling a language that's not really amenable to static compilation, the boot image initialization process could include a custom script to run functions that are known to be hot, to warm up the JIT compiler and include the compiled code in the boot image.
- fijal 11y ago
  If you measure across those benchmarks, it indeed plateus. However, we've been doing a lot of work on stuff that's not taken into the account to the average, notably: * external calls (IO, cffi, etc.) * warmup speed * STM * tons of small things with various external libs Now this is obviously our own fault that we don't have good enough benchmarks, but it definitely does not plateu for everyone. Notably we're trying to address places where PyPy does not outperform CPython by 7x - if you get 7x performance improvement you're likely very happy. In real world gains can be smaller and we would rather tackle those first. We're working on memory impact too btw. Compatibility is pretty much "done" (complain if it does not work for you)
deleted 11y ago
[deleted]
JSno 11y ago
why cares..no one uses it.
1st1 11y ago
I know that instead of asking I should either go and donate more money, or go and do the coding myself, but: is it possible at all that PyPy devs can focus and produce a stable PyPy for python 3.3 (at least)? Looks like it's almost there (but this almost stretches over many years now), it just needs a little push.
- rlamy 11y ago
  Well, there is a GSoC student working on precisely that, right now.
- fijal 11y ago
  So it's very hard to get all PyPy devs to focus on Python 3.3. Money can change the direction, but there are also features that are important to us, like warmup time and STM that we don't want to give up for 3.3. Additionally, 3.3 has very little business value. All PyPy customers use Python 2 (the ones that can buy commercial support at least) and small performance improvements matter more to them.
  - plorkyeran 11y ago
    > All PyPy customers use Python 2 Well yes, your customers will generally pay for the product that actually works and is useful now, and not the experimental and incomplete one that's several versions behind.
    - 1st1 11y ago
      Exactly. At this point, 7 years since python 3.0 was first released, PyPy's lack of interest towards it is starting to harm the community.
      - JulianWasTaken 11y ago
        That isn't a fair complaint to levy on the PyPy developers. We are one of those paying customers (on occasion), for instance, and there is no benefit for us for work on PyPy 3 and potential large benefit from some of the upcoming work on PyPy 2. If people see benefit from PyPy 3 they should donate to motivate work on it.
h43k3r 11y ago
I have been benefitted a lot by PyPy. I made a search engine[1] in python for one of my university course project. It had to process 30+ GB of html files. I got a 2x improvement by using PyPy and completed indexing the dataset in 11 hours as compared to projected 22 hours. The only explanation I can think of is that my work was compute intensive and involved a lot of loops and accessing data in dictionaries. [1] https://github.com/shobhit6993/webGrep https://github.com/shobhit6993/webGrep
- ngoldbaum 11y ago
  A factor of two doesn't sound that great actually. You can get similar speedups by "compiling" an arbitrary python module using cython. Of course you can usually do much better than a factor of two if you think carefully about type annotations and CPython overhead.
  - gtaylor 11y ago
    > A factor of two doesn't sound that great actually. A factor of two sounds great to me, especially if he didn't have to write Cython-specific code. That's a nice, easy win with a noticeable impact.
  - fijal 11y ago
    it's a factor of two without thinking too hard. You can probably optimize it for pypy too which will get you more benefit. If it's "just" dict lookups there is not really all that much there is to win using cython for example

147 points by mattip 11y ago

PyPy 2.6.0 - "Cameo Charm" since PyPy looks best in profile

A few data points and questions: - it appears PyPy performance improvements have begun to plateau [1] - what's not measured is memory consumption in comparision to CPython. I've read anecdotal evidence that indicates PyPy is increase in memory usage [2] - I also have not found a chart that depicts how compatible PyPy is vs CPython. If someone had a chart of this over time, that'd be great. [1] http://speed.pypy.org/ http://speed.pypy.org/ [2] http://stackoverflow.com/questions/29000279/pypy-memory-usage-increasing-over-time http://stackoverflow.com/questions/29000279/pypy-memory-usag...

deleted 11y ago
[deleted]
maheart 11y ago
> - it appears PyPy performance improvements have begun to plateau [1] It does appear that Pypy's performance is reaching some asymptotic limit, but there's always new avenues to investigate. e.g. The STM branch of Pypy removes the GIL, and allows code to scale nicely across cores[1] [1]http://morepypy.blogspot.ch/2014/07/pypy-stm-first-interesting-release.html http://morepypy.blogspot.ch/2014/07/pypy-stm-first-interesti...
chrisseaton 11y ago
I think there are still whole classes of optimisations that PyPy doesn't do yet but could, aren't there? Vectorisation, for example? There's no way they have exhausted all possible compiler optimisation avenues that are known.
mattip 11y ago
Performance improvements have been driven by user-reported slowdowns. The more users that report performance problems, the more the entire community profits. There are more performance improvements on the way: STM [1] will do away with the GIL in a transparent way, we have a GSOC underway to teach the JIT to use SIMD coprocessor commands, and hopefully CFFI 1.1 [2] will smooth the corners where there is no escape from C code. Memory use is very application dependent. I cannot improve on the answer given to the question on SO. As far as compatibility goes, PyPy 2.6.0 uses the CPython 2.7.9 stdlib - pure python code is 100% compatible (barring bugs). Packages such as Pillow [3] have made sure they are PyPy friendly even where they use C code. Numpy [4] is still a work-in-progress but much of it already works (we are implementing version 1.9.0 for now). The surface area is huge and very wrinkled, so it will take some time to finish all the corners. Please try it out and let us know if your code doesn't run. [1] http://pypy.org/tmdonate2.html http://pypy.org/tmdonate2.html [2] https://cffi.readthedocs.org https://cffi.readthedocs.org [3] https://python-pillow.github.io https://python-pillow.github.io [4] http://buildbot.pypy.org/numpy-status/latest.html http://buildbot.pypy.org/numpy-status/latest.html
- joshuapants 11y ago
  > PyPy 2.6.0 uses the CPython 2.7.9 stdlib - pure python code is 100% compatible (barring bugs) Is it possible to use PyPy with py2exe or freeze so that I can distribute a Python application to someone so that they don't have to go and install PyPy to get performance benefits?
  - mwcampbell 11y ago
    I'd like to propose a different approach to that problem, one that also addresses the issue of startup time: a boot image. I got the name from the Avian JVM (https://github.com/ReadyTalk/avian https://github.com/ReadyTalk/avian), but a similar concept can be seen at least as far back as GNU Emacs in the 90s. The idea is that as part of the build process, you load all of a program's code and initial data into memory, then dump the heap. Then at startup, you just have to map the heap back into memory, and possibly fix up pointers if you can't load everything at the same address as before. Of course, you'd have to make sure that none of the objects in the saved heap contain handles to external resources like files. Also, for PyPy, which is JIT-compiling a language that's not really amenable to static compilation, the boot image initialization process could include a custom script to run functions that are known to be hot, to warm up the JIT compiler and include the compiled code in the boot image.
fijal 11y ago
If you measure across those benchmarks, it indeed plateus. However, we've been doing a lot of work on stuff that's not taken into the account to the average, notably: * external calls (IO, cffi, etc.) * warmup speed * STM * tons of small things with various external libs Now this is obviously our own fault that we don't have good enough benchmarks, but it definitely does not plateu for everyone. Notably we're trying to address places where PyPy does not outperform CPython by 7x - if you get 7x performance improvement you're likely very happy. In real world gains can be smaller and we would rather tackle those first. We're working on memory impact too btw. Compatibility is pretty much "done" (complain if it does not work for you)

deleted 11y ago

[deleted]

JSno 11y ago

why cares..no one uses it.

1st1 11y ago

I know that instead of asking I should either go and donate more money, or go and do the coding myself, but: is it possible at all that PyPy devs can focus and produce a stable PyPy for python 3.3 (at least)? Looks like it's almost there (but this almost stretches over many years now), it just needs a little push.

rlamy 11y ago
Well, there is a GSoC student working on precisely that, right now.
fijal 11y ago
So it's very hard to get all PyPy devs to focus on Python 3.3. Money can change the direction, but there are also features that are important to us, like warmup time and STM that we don't want to give up for 3.3. Additionally, 3.3 has very little business value. All PyPy customers use Python 2 (the ones that can buy commercial support at least) and small performance improvements matter more to them.
- plorkyeran 11y ago
  > All PyPy customers use Python 2 Well yes, your customers will generally pay for the product that actually works and is useful now, and not the experimental and incomplete one that's several versions behind.
  - 1st1 11y ago
    Exactly. At this point, 7 years since python 3.0 was first released, PyPy's lack of interest towards it is starting to harm the community.
    - JulianWasTaken 11y ago
      That isn't a fair complaint to levy on the PyPy developers. We are one of those paying customers (on occasion), for instance, and there is no benefit for us for work on PyPy 3 and potential large benefit from some of the upcoming work on PyPy 2. If people see benefit from PyPy 3 they should donate to motivate work on it.

h43k3r 11y ago

I have been benefitted a lot by PyPy. I made a search engine[1] in python for one of my university course project. It had to process 30+ GB of html files. I got a 2x improvement by using PyPy and completed indexing the dataset in 11 hours as compared to projected 22 hours. The only explanation I can think of is that my work was compute intensive and involved a lot of loops and accessing data in dictionaries. [1] https://github.com/shobhit6993/webGrep https://github.com/shobhit6993/webGrep

ngoldbaum 11y ago
A factor of two doesn't sound that great actually. You can get similar speedups by "compiling" an arbitrary python module using cython. Of course you can usually do much better than a factor of two if you think carefully about type annotations and CPython overhead.
- gtaylor 11y ago
  > A factor of two doesn't sound that great actually. A factor of two sounds great to me, especially if he didn't have to write Cython-specific code. That's a nice, easy win with a noticeable impact.
- fijal 11y ago
  it's a factor of two without thinking too hard. You can probably optimize it for pypy too which will get you more benefit. If it's "just" dict lookups there is not really all that much there is to win using cython for example