[pypy-dev] Question on the future of RPython
sarvi at yahoo.com
Thu Sep 2 10:10:06 CEST 2010
If PyPy is using RPython for its compiler implementation, it should and will be
optimized eventually for its compiler/JIT to to be fast.
Which just tells me that the performance gap between Shedskin and PyPy will be
narrowed/beat pretty soon.
I would still rather work with just one interpreter/compiler, say PyPy.
Better than using PyPy/CPython for an interpreter and Cython/Shedkin for
compiling, without interpreter support during development.
I am just seeing Cython/Shedskin as fragmentation of resources.
A lot more could accomplished if these projects came together with PyPy.
If you ask this question on the Shedskin/Cython alias as to why they shouldn't
pool resources into making the PyPy RPython compiler into a First class
citizen/goal of PyPy.
They will immediately tell you its not a goal PyPy.
Why not officially make it so.
Formalize RPython and its compiler.
Obviate the need for Cython/Shedskin and get them on board.
Like the example I quoated. Mercurial is 95% python 5% C for peformance. It
should be 95% python and 5% RPython.
We have Pickle and cPickle for performance. The Pickle could have simply been
rewritten in RPython and probably compiled and we don't need different versons
----- Original Message ----
From: Douglas McNeil <mcneil at hku.hk>
To: Saravanan Shanmugham <sarvi at yahoo.com>
Cc: "pypy-dev at codespeak.net" <pypy-dev at codespeak.net>
Sent: Wed, September 1, 2010 11:27:32 PM
Subject: Re: [pypy-dev] Question on the future of RPython
> No other python implementation can convert python programs to executables.
There's shedskin, which is actually very good as these things go:
Like RPython, you have to write in a small subset of python which can
be a little frustrating once you've gotten used to pythonic freedom.
But I've found it very useful for some short numerical codes (putting
on my OEIS associate editor hat). And Cython is pretty powerful these
ObPyPy: the other day I had cause to run a very short, unoptimized,
mostly integer-arithmetic code. With shedskin, it took between ~42s
(with ints) and ~1m43 (with longs), as compared with only ~3m30 or so
to run under pypy. That's only a factor of two (if I'd needed longs).
Both could be much improved, and a lower-level version in C would
beat them both, but I was very impressed by how little difference
there was. Major props!
For numerics it'd be interesting to have a JIT option which didn't
care about compilation times, and instead of generating assembly
itself generated assembly-like C which was then delegated to an
Department of Earth Sciences
University of Hong Kong
More information about the Pypy-dev