4 ms·

A few data points and questions: - it appears PyPy performance improvements have begun to plateau [1] - what's not measured is memory consumption in comparisi

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.
    - chadzawistowski 11y ago
      Many Common Lisps seem to redistribute applications this way - great suggestion. Do you know of any tools that would help someone pull off a coredump for arbitrary Python code?
      - mwcampbell 11y ago
        Re: Common Lisps implementing this, yeah, I'd noticed that SBCL did this. Speaking of SBCL, a disadvantage of boot images is that the implementation is sometimes non-portable; for example, SBCL's Windows support is still experimental. To answer your question, I'm pretty sure that support for a boot image would have to be baked into PyPy, or whatever Python implementation you want to use.
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]

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.
  - chadzawistowski 11y ago
    Many Common Lisps seem to redistribute applications this way - great suggestion. Do you know of any tools that would help someone pull off a coredump for arbitrary Python code?
    - mwcampbell 11y ago
      Re: Common Lisps implementing this, yeah, I'd noticed that SBCL did this. Speaking of SBCL, a disadvantage of boot images is that the implementation is sometimes non-portable; for example, SBCL's Windows support is still experimental. To answer your question, I'm pretty sure that support for a boot image would have to be baked into PyPy, or whatever Python implementation you want to use.

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)