> NumPy which requires installation of our fork of upstream numpy...

At some point in the past, there was a "numpypy" -- does that name still describe PyPy's fork?

Does the numpy team see a forward path where they can take some of these changes back upstream (presumably some/all of the changes could support CPython and PyPy)?

Anyways, keep up the great work! I'm always happy to see my code scream on PyPy for a "free" speed boost.

IMO numpy support is probably one of the few barriers other people see to utilizing pypy more.

IIRC the reference implementation is optimized for readability rather than speed, so I doubt this will happen.

It's great that they are splitting the RPython docs out from the PyPy ones.

One thing I found lacking while writing a simple BrainFuck interpreter in RPython is lack of documentation on the best practices with regards to speed. Should I use classes, namedtuples or even just tuples to pass data around? Using a list seemed to slow things down a lot in some places but not others etc.

Apart from that I highly recommend people give PyPy a go if you're going to be writing an interpreter.

Do you have any resources for this? I was thinking of looking into that but don't know where to start.

BrainFuck is a great place to start because it's pretty simple. I started with this post on the PyPy blog: http://morepypy.blogspot.co.uk/2011/04/tutorial-writing-inte...

This repository helped as well: https://github.com/thoughtpolice/bf-pypy

Getting a basic interpreter working wasn't hard, but I attempted to add a few of the optimizations listed here[1], which meant adding some form of AST and stuff to manipulate it. This is where I got a bit stuck with regards to performance as some of my optimizations meant the program should have been faster, but instead it slowed down.

1. http://calmerthanyouare.org/2015/01/07/optimizing-brainfuck....

PyPy project maintains an example interpreter to learn from.

https://bitbucket.org/pypy/example-interpreter

They have been trying to improve the exact specification of RPython since David Beazley sorta called the project out on the fact that, for a time early in the development of PyPy, RPython was basically whatever subset of Python survived the PyPy build process. The 2012 PyCon keynote gives and awesome explanation of the project internals and its promise: https://www.youtube.com/watch?v=l_HBRhcgeuQ

"We continue to asymptotically approach a score of 7 times faster than cpython on our benchmark suite, we now rank 6.98 on latest runs".

This is obviously as meaningless as it gets, since it's an average on really a random set of benchmarks. But it generally means we're getting faster (with number 7 not meaning anything in particular)

Would love to see run-once, latency, and memory benchmarks. The benchmarks don't show many of the GC improvements, or track how quickly the JIT works for example.

This is yet again, a multi-month project that I simply don't have budget for. Would love to see a business model where writing such parts would be somehow monetizable

Ok, some things that I've done...

Get a high paying python contract, and then donate some proceeds to other cheaper developers. You should be able to get $200K-$300K as a contractor for one years work (or more).

Somewhere in big data, finance, games, or other places that pay for performance - that also use python a lot.

Once you are embedded, it is much easier to do sales for other pypy related contracts. eg. if one of your team were at facebook, dropbox, or google - it may have been your team who got those VM projects. This is a sales tactic that many consulting shops use.

A sponsorship approach seems to work for some FOSS projects. As does conferences.

Helping students with grant proposals can also bring in a lot of effort. This is something the pypy project does of course. But just mentioning it for other people who may read.

If your goal is helping the pypy project these could all work. For me, I've used these approaches for FOSS projects with some success.

speed.pypy as a service could probably be sold. For example as a devpi project that others could use. Reduce server costs by helping the development team speed up their code. It's got a pain point, a cost saving, and pretty graphs.

it's all A LOT more difficult if you don't live in America.

I actually have some examples that run faster in CPython. However, that's mostly idiomatic -- the code can be written to favor one interpreter or the other in terms of speed.

Great, but I personally can't wait for Python 3.4 support due to asyncio!

Have to agree here! We're working on a server I'd love to run and optimise for PyPy, just need to wait 'til 3.4 and asyncio ships.

Also great work on the project in general, PyPy has made Python work as a platform for a few previous projects where standard Python wouldn't have been usable.