
PyPy 1.5 Released: Catching Up - jnoller
http://morepypy.blogspot.com/2011/04/pypy-15-released-catching-up.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+PyPyStatusBlog+%28PyPy+Status+Blog%29
======
amix
I did a benchmark of Unladed Swallow 1.5 years ago and at this time PyPy
looked like a very academic project. It could not really run any interesting
code. At this time Unladed Swallow looked like a great project since improving
cPython rather than starting from scratch seemed much easier, especially since
Unladed Swallow based their JIT optimization on LLVM's JIT engine.

I also recall reading PyPy's blog, especially a blog post about their Prolog
based JIT prototype and I thought "wow, this sure seems like a complicated way
to implement a JIT engine, I wonder if they will ever implement something that
can run real code".

Fast forward to today and Unladed Swallow is dead and PyPy has implemented a
Python implementation that's compatible with Python 2.7 and beats cPython 2.6
on various benchmarks. Pretty impressive and kudos to the PyPy team.

~~~
luismgz
Many people seem to ignore that pypy is not a new project. It's been on the
works for more than 8 years now.

~~~
illumen
It's also had a lot of funding, and more full time workers than on CPython
(who has zero full time coders).

------
sciurus
I'm impressed that they support the features of CPython 2.7 already. PyPy
seems to be developing much faster than other alternate python
implementations.

~~~
kingkilr
IronPython actually beat us to 2.7, however I will note that it was pretty
fast. We went from 2.5 to 2.7 support in under 12 months.

~~~
kbd
I will love it if in a couple of years the mainstream implementation of Python
is PyPy. People are going to be upgrading their Python installations anyway
when they move to Python 3. If y'all can get Python 3 support in, maybe people
will switch to PyPy at the same time.

I just wish Google would throw some support your way.

~~~
sho_hn
Indeed, what are your current plans for Python 3.x?

~~~
kingkilr
Future cloudy, ask again later :) Because of the way our JIT is written it
would be entirely possible for us to branch for py3k and put JIT improvements
on both with relatively little effort, it's likely that at least our next
release will still be 2.x and just feature optimizations though.

~~~
sho_hn
Here's one vote for focussing on py3k sooner rather than later, fwiw :). I
understand you're anxious to reap some rewards and see (more) production use
at this point, but as a big fan of much of what was done to the language in
py3k and having made the switch already, PyPy vs. CPython 3.x is an unhappy
dilemma for me :).

~~~
TillE
For me (and I suspect quite a lot of other people), PyPy and CPython 3 both
suffer from the same problem: lack of support for third-party libraries.
Moving to Py3k would only exacerbate that problem for PyPy, removing their
current support for the likes of Django and Twisted.

~~~
sho_hn
I'd assume they'd very likely keep up support for Python 2.7.x for quite some
time past the first py3k-compatible release, similar to what CPython is doing.

Although personally I actually wouldn't mind giving up one for the other, as
that would allow PyPy to act as an extra incentive to drive py3k adoption in
third-party libraries. Of course I understand if the PyPy developers don't
just want to use their hard work as a gaming piece to drive the py3k adoption
agenda, though :).

------
carlosedp
I wonder how hard is the integration of Stackless and the JIT features. That
would be killer.

~~~
kingkilr
There's actually a sprint going on right now (where this release was done),
and that was a topic of discussion. I don't think anyone has written up the
conclusions yet, but estimate I heard was that it'd be about 1-month of
person-work.

~~~
carlosedp
Fantastic... Christian worked hard on Stackless and I think it`s a great
feature. On Pypy it would be easier to maintain and add functionality,
unfortunately, I struggle on Stackless internals and it`s low level C gimmicks
so I can't help on it. It would be great to have something like a good
framework in the future to make it`s adoption easier. We have the Stackless
Examples project to address this initial learning curve thing.
<http://code.google.com/p/stacklessexamples/>

~~~
carlosedp
Nice, the CCP guys are great maintaining Stackless... Kristjan and Richard do
a great job on it. If there are any clues or tips on how can I help out, it
would be a pleasure.

~~~
euccastro
Have you asked in the Stackless mailing list?

------
ch0wn
Any chance you could update your Ubuntu PPAs soon?

~~~
thristian
My sentiments exactly: I would love to have a reasonably up-to-date PyPy
around to try things in, but I'm not yet so invested in the project that I'm
willing to watch for release announcements and download source-tarballs (or
binary tarballs). Having a reliably updated PPA is pretty much exactly what
I'm looking for.

------
va_coder
Maybe this is a dumb question but why not just work on making CPython faster?

Edit: I guess this provides insights:

<http://codespeak.net/pypy/dist/pypy/doc/architecture.html>

~~~
kingkilr
I wish I could find the video the talk where we explained this in great
detail, but basically: it's hard, it's been tried and failed (notably by Armin
Rigo, one of the leads of PyPy). Adding a new GC to CPython is insanely hard,
and manually writing a JIT for Python even moreso.

------
nickik
I'm not really intressted in the Python interpreter that pypy is but the other
part pypy (the toolchain) is maybe the best thing since sliced bread.

I have the plan to start working on the scheme implmentation.

The thing I don't really like about the project is that it has one name for
two things. I can understand how that came about historicly but I think the
should make two names out of it.

~~~
kingkilr
We've started referring to it as the "RPython translation toolchain" which
will hopefully reduce confusion.

~~~
nickik
You should think of a snappier name. Other than that keep up the good work.
I'm atm reading all the pypy papers, very cool.

~~~
fijall
you should have a look at scheme interpreter that was written already maybe:
<https://bitbucket.org/pypy/lang-scheme/overview>

------
erez
I'm really interested in this project. The abundance of C as "the new machine
language" for language implementation, as well as the JVM-based languages,
makes me wonder what it means for the programming language landscape. I would
be very interested in learning whether this un-C implementation made any
difference to Python, and what can be learned from it in way of other language
implementations

------
justincormack
The benchmark here <http://attractivechaos.github.com/plb/> suggests they are
doing much better on performance than they were a while back. Its a straight
numeric benchmark so not relevant for everything but its better than V8 which
is good work.

~~~
kingkilr
1.5 should be a lot better on these, the Loop Invariant Code Motion really
helps on very tight loops, as these benchmarks often have.

~~~
justincormack
Thats great. Dynamic languages at say Java like speeds is a real game changer
over the PHP/Rubylevel speeds. At the moment we only have LuaJIT proving its
possible, but PyPy is the next contender.

~~~
swannodette
While this is great news for Python, there are quite a few dynamic languages
now beyond LuaJIT showing that it's possible to get stellar perf - JavaScript,
Racket, Clojure.

~~~
kragen
Last I heard, no JS engine was close to LuaJIT's performance; they were all
worse by a factor of five or so. Clojure being in the LuaJIT ballpark would
surprise me (do you have benchmarks?) but Racket wouldn't. (But I wouldn't
call Scheme a dynamic language!)

~~~
swannodette
[http://shootout.alioth.debian.org/u64/which-language-is-
best...](http://shootout.alioth.debian.org/u64/which-language-is-
best.php?gpp=on&java=on&sbcl=on&ghc=on&csharp=on&clojure=on&racket=on&v8=on&hipe=on&lua=on&python3=on&vw=on&yarv=on&xfullcpu=1&xmem=0&xloc=0&nbody=1&fannkuchredux=1&meteor=0&fasta=1&spectralnorm=1&revcomp=1&mandelbrot=1&knucleotide=1&regexdna=1&pidigits=1&chameneosredux=0&threadring=0&binarytrees=1&calc=chart)

Clojure 1.2.0 is already faster than Racket. Version 1.3.0 will probably bring
it close to Go territory on those benchmarks.

For my own work I've found that getting Clojure in the Java ballpark is
certainly possible.

~~~
igouy
[http://shootout.alioth.debian.org/u64/benchmark.php?test=all...](http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=racket&lang2=clojure)

~~~
kragen
Yeah, I was wrong about Racket:
[http://shootout.alioth.debian.org/u64/benchmark.php?test=all...](http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=racket&lang2=gcc)

------
john7
Can numpy be used with pypy? Or are there plans for that?

~~~
kingkilr
There are plans, but nothing yet, this reddit thread has some decent
information:
[http://www.reddit.com/r/Python/comments/h0uuv/pypy_15_releas...](http://www.reddit.com/r/Python/comments/h0uuv/pypy_15_released_catching_up/)

~~~
hyperbovine
I'd like to second the request for a very detailed blog post written by one of
the PyPy devs on how interested parties can contribute to the development of
Numpy on PyPy. Lack of Numpy support is the showstopper for me and a lot of
other people in terms of switching over -- almost everybody who wants faster
Python is using Numpy in some way or another :-) This is something I would be
really interested in working on.

------
wnoise
Why did they decide on a name that can easily be (mis)pronounced as a synonym
for urine? That just seems like a poor branding decision, up there with "blur-
ray".

~~~
njharman
What language uses "ee' sound for "y"?

And who pronounces blue, blur?

~~~
euccastro
Spanish does.

Not agreeing with grandparent, though. Lots of people admit to playing with
their Wiis for hours a day.

