

PyPy 2.6.0 released - mattip
http://morepypy.blogspot.com/2015/06/pypy-260-release.html

======
tiffanyh
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-
usag...](http://stackoverflow.com/questions/29000279/pypy-memory-usage-
increasing-over-time)

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

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

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

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

~~~
fijal
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".

~~~
1st1
> 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.

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

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

