PyPy 2.6.0 released | Hacker News Reader

PyPy 2.6.0 released

morepypy.blogspot.com

147 pointsmattip28 comments

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/ [2] http://stackoverflow.com/questions/29000279/pypy-memory-usag...

> - 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-interesti...

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.

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

[2] https://cffi.readthedocs.org

[3] https://python-pillow.github.io

[4] http://buildbot.pypy.org/numpy-status/latest.html

> 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?

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), 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.

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?

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.

Lisp 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, ...

+1 on this - we distribute python code on legacy windows platforms and the ability to freeze an app is mandatory for us.

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)

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

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.

> 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.

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

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.

Well, there is a GSoC student working on precisely that, right now.

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.

> 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.

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.

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.

Pay for it and there will be interest - its simple. It's not that they are against it - they just need to work on things that make the project alive.

And this sort of attitude is exactly why I hate Python 3 personally. "Work for free on Python 3 adoption or you're harming the Python community".

> And this sort of attitude is exactly why I hate Python 3 personally. "Work for free on Python 3 adoption or you're harming the Python community".

Sorry if I offended you with my comment, it wasn't my intent.

I guess there is a way to view this in a different light: PyPy is a major Python implementation, that is used by a lot of people. There creates ~some~ responsibility.

Also, using "hate" word is precisely the problem -- it's not a first time I hear that from PyPy devs. I just hope that you hate only that aspect of the whole "Python 3 Saga", not the language itself.

to answer just one aspect of your post - I have absolutely nothing against python 3 as a language :-)

The harm to the community was done by forking an incompatible language, fracturing it, and expecting people to spend their free time going along with it (usually in the form of writing Python 3-compatible Python 2 code, which is the worst of all possible worlds). If you're going to rewrite your code in a language that many of your users don't have installed already and several of your libraries don't yet support, there are plenty of other compelling languages to write in and fund development in.

It's also at least possible that the Python community is in better shape with a stable 2.7 and increasingly better 3.x than it would be with a Python 2.11 that just broke abi compatibility again.

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

Reply on news.ycombinator.com