Hacker News new | past | comments | ask | show | jobs | submit login
PyPy's future directions (lostinjit.blogspot.com)
145 points by jemeshsu on Oct 8, 2011 | hide | past | web | favorite | 18 comments

I think one of the most exciting things about PyPy that sometimes get lost is that it's not only a great interpreter, it's a great interpreter construction toolset. I like python the language itself quite a bit, but if I were writing an interpreter for a new language PyPy would probably be the platform I'd want to implement it on.


"Translating RPython to C is pretty cool, but one of the best features of PyPy is its ability to generate just-in-time compilers for your interpreter. That's right, from just a couple hints on how your interpreter is structured, PyPy will generate and include a JIT compiler that will, at runtime, translate the interpreted code of our BF language to machine code!"

Hmm... I wonder how hard a native CoffeeScript on pypy would be...

Or JavaScript, that would work as well.

I was doing a homework for an algorithms class today. I wrote a quick implementation in Python with some quickcheck tests to make sure it worked correctly. Running 10,000 tests with CPython 2.7 took 136s on my laptop. For fun, I tried with the latest PyPy and it ran the 10,000 tests in 30s. This is very impressive and I am definitely going to start using PyPy more often.

I have been recently porting to Python (with NumPy) some badly written C++ code. I was really shocked that the performance drops nearly 100 times (because of many nested loops).

NumPy working on PyPy would probably get me really near original performance. And it's not the advanced features I hope for -- ndarray and basic linalg operations is all I need to do my thesis.

Anyway guys, great job so far, looking forward to the future.

If you have nested loops, numpy will indeed not help you. Numpy per-item access is actually slower than python usual container (list, tuple). You could post the code that is actually slow, so that one could help you to make it faster.

As for pypy helping you, I hope that's the case. But what's in pypy today has not much to do with numpy, in the sense it is a complete re-implementation from scratch.

You should read http://www.scipy.org/PerformancePython if you haven't already seen it since it deals with the performance of nested loops. The only issue I guess would be portability, for example to PyPy.

I totally missed this guide. I'd definitely use Cython to optimize this.

Previously I used Cython to wrap original C++ code and it performed really well but I got numerical differences in result.

This does not cover PyPy and under PyPy behavior of those methods will be Very different.

Have a look at suggestions here:


By far the most important first-order optimizization is to vectorize your computations.

What are the options for using pypy with wsgi?

Any pure-python WSGI server works: gunicorn, cherrypy's server, wsgiref/werkzeug.serve, probably Aspen.

I'm pretty certain mod_wsgi does not work with Pypy (it uses Python's embedding API, which Pypy does not implement), I have no idea about uWSGI although messages like this: http://lists.unbit.it/pipermail/uwsgi/2011-March/001641.html make me thing it should be possible.

Also, Tornado, which may be twice as fast:


As far as I know, while a Tornado (framework) application can run in a WSGI server via tornado.wsgi, Tornado's evented server does not support mounting WSGI application.

thadeus_venture was specifically asking about WSGI.

Why does the official Python development still take part in CPython rather than PyPy? Is there anything seriously wrong with PyPy, so it can't replace CPython by now?

The main reason, aside from simple inertia, is that C extension API support is still only alpha.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact