Ten years of PyPy

http://morepypy.blogspot.de/2013/02/10-years-of-pypy.html

by DasIch • 13 years ago

200 32 13 years ago

morepypy.blogspot.de

I'm personally very excited about the prospects for NumPy in PyPy, as this is my main use case for python. Relatedly, on the PyPy homepage, you can give money to help grease the wheels on development of specific PyPy features: http://pypy.org/. There's also quite detailed proposals that describe where the money will go, how it will help each feature's development, why each feature is useful/cool, etc. To me this seems like a really awesome way to organize donations for an open source project and gives me greater confidence that my donation will have an impact.

hyperbovine• 13 years ago

I am excited too, but I also wonder how much faster it's really going to be. Synthetic benchmarks are great, but I didn't see much of a speedup when I switched to PyPy for some of my real-world code.

fijal7• 13 years ago

You should complain. There is a myriad of reasons why PyPy won't go very fast, for example you're using C extensions. Usually what happens if you have code where parts go insanely fast and parts go insanely slow. Once you identify it, sometimes it is just replacing the library (like pgsql2 -> pgsql2cffi or so) and stuff flies. But it all depends on your workload and the stack a lot. R&D is typically needed to get good speedups. For most RW examples, 2-10x are to be expected.

Shameless plug - if your stuff is not open source and you can't be bothered to do the profiling yourself, there is typically an option to hire someone to do it for you. Get in touch.

zwegner• 13 years ago

Same here--I spent a couple days porting a compiler frontend from Python 3->2 just to try out PyPy, and got rewarded with a 2-3x slowdown. I messed around with some tracing parameters, but didn't get too much benefit IIRC.

Of course, this was a couple years ago, and I don't have access to that codebase anymore. Things might've changed since then...

edwkar• 13 years ago

I'm using PyPy for real-world code every day, because it runs fast as^H^H^H^H, uhm, very fast! I regularly see 6-15X speedups compared to CPython.

That being said, if your code is mostly IO-bound or calls into foreign-language libraries, PyPy's speedup of the Python code of course won't help much with your wall time.

synparb2• 13 years ago

You might also check out numba (http://numba.pydata.org/), which still feels slightly beta, but can speed up numpy code quite a bit with very little boilerplate. I've started experimenting with it as an alternative to my usual approach which is to write or wrap code with Cython. I'm curious to see where PyPy goes with numpy and cffi though.

bdr• 13 years ago

Awesome. Is there somewhere they've documented the wisdom they've gained in more detail? I'd love to hear more about the issues encountered with JavaScript, ctypes, and LLVM, and lessons learned in general.

fijal7• 13 years ago

#pypy on freenode. LLVM, JS and ctypes are scattered around mailing list posts as well (and blog posts).

opminion2• 13 years ago

To make it more likely to be accepted, the proposal for the EU project contained basically every feature under the sun a language could have.

How common is this in EU projects?

ajuc• 13 years ago

Very, at least in the education funding. There are courses (financed by EU, of course) that teach you how to write proposals for EU projects, to make it seem more in line with expectations of the "program" you want to finance your project. They basically say "you have to put 'developing intelectual capital among unemployed people in the countryside' there, that is more likely to get you the money. You may do a few free courses for 50 people on whatever in that building after it's finished, and it will be OK. And while your're at it buy projector and laptop for that courses too, and put it in costs". And the building is intended as library or sth, but to get money you add whatever you can.

EU money on education are wasted so much. On the other hand infrastructural funds are handled more or less OK.

haddr• 13 years ago

guy working on several EU research projects here.

That's barely true. Although there is some certain amount of buzzwords in every proposal (that's kind of bread an butter for tech people anyway), they are far from what OP says. Sometimes there is some overpromising, but those things are usually secondary aspects, rather than the core idea. Most of the results are beeing used as some developed components by participating companies, some of the work is dropped, and a lot of work is open sourced and few projects are really successful. But that's research anyway. Not all work lead to success here.

fijal7• 13 years ago

I can't speak about the EU projects in general, but chances are we overdid it and it's not 100% clear if it increased or decreased our chances.

throwaway54-762• 13 years ago

This reminded me to make another donation towards py3k support =). Keep on rocking on, pypy.

slurgfest• 13 years ago

From the article: "the first usable PyPy was released in 2010." For most practical purposes PyPy is only two years old, not ten.

chewxy2• 13 years ago

No. Before it was known as PyPy, PyPy was known as Psyco. I remembered playing with it. In Pressyo's internal documentation there were many mentions of using Psyco (we never actually ended up using it)

pangram• 13 years ago

I think Psyco was a separate code base, and not an actual progenitor of PyPy.

fijal7• 13 years ago

Working pypy was released before that. The first release that had a JIT that made stuff faster was released in 2010. So a lot of codebase is much older than that.

TheCondor• 13 years ago

I recommend using it. It's a great platform. Well done guys

pjmlp• 13 years ago

Still hoping one day CPython gets replaced by PyPy as default Python implementation.

Good work guys.

daemon13• 13 years ago

According to PyPy site it can run Django.

Was it tested or anyone used it in production to run Dj 1.4? Dj 1.5?

evilpie• 13 years ago

I actually find it very impressive that they have a quite well working tracing JIT. For Firefox we had TraceMonkey, but the code was hard to maintain and hacked into the infrastructure. And it turned out that most stuff doesn't trace very well in the real world. (not SunSpider, argg!) I haven't looked very recently but I guess the pypy frontend for JavaScript is still not actively maintained? I think I remember seeing some thesis about that recently. Best of luck to them in the coming years!

Ten years of PyPy

Related Stories