

PyPy 2.5.1 released - alexcasalboni
http://morepypy.blogspot.com/2015/03/pypy-251-released.html

======
wyldfire
> 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.

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

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

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

~~~
orf
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...](http://morepypy.blogspot.co.uk/2011/04/tutorial-writing-
interpreter-with-pypy.html)

This repository helped as well: [https://github.com/thoughtpolice/bf-
pypy](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....](http://calmerthanyouare.org/2015/01/07/optimizing-
brainfuck.html)

------
twsted
"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".

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

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

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

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

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

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

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

