PyPy 2.6.0 released

http://morepypy.blogspot.com/2015/06/pypy-260-release.html

by mattip • 11 years ago

147 28 11 years ago

morepypy.blogspot.com

mattip2• 11 years ago

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

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

maheart• 11 years 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-interesti...

chrisseaton• 11 years 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.

mattip2• 11 years 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

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

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

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

joshuapants• 11 years 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?

fijal5• 11 years 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)

1st13• 11 years 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• 11 years ago

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

fijal5• 11 years 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• 11 years 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.

h43k3r• 11 years 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

ngoldbaum• 11 years 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• 11 years 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.

fijal5• 11 years 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

PyPy 2.6.0 released

Related Stories