3 ms·
Performance improvements have been driven by user-reported slowdowns. The more users that report performance problems, the more the entire community profits. Th
by 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 agoI'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 agoMany 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 agoRe: 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.
- lispm 11y agoLisp did that in the 1960s. BBN Lisp for example... Most Common Lisp implementations still do it today: SBCL, Clozure CL, LispWorks, Allegro CL, CLISP, ... Yeah, filling caches before dumping and keeping caches filled is also common... More advanced implemenations could write incremental image dumps, based on other image dumps, ...
- sandGorgon 11y ago+1 on this - we distribute python code on legacy windows platforms and the ability to freeze an app is mandatory for us.