On 10/11/2010 1:47 PM, Ryan Kelly wrote:
On Mon, 2010-10-11 at 13:01 -0700, John Nagle wrote:
It may be time to standardize "RPython".
There are at least three implementations of "RPython" variants - PyPy,
Shed Skin, and RPython for LLVM. The first two are up and running.
There's a theory paper on the subject:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.142.1457&rep=rep1&type=pdf
All three have somewhat different restrictions:
PyPy's Rpython:
http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html
Shed Skin:
file:///C:/Users/nagle/AppData/Local/Temp/shedskin-tutorial-0.3.html
Rpython for LLVM:
http://code.google.com/p/rpython/
So a language standardization effort, independent of CPython,
would be useful.
A similar topic was recently discussed on the pypy-dev mailing list:
http://codespeak.net/pipermail/pypy-dev/2010q3/006170.html
My interpretation is that the pypy devs are -0 on such a standardisation
effort, as it would give them less flexibility in moulding rpython for
their specific needs. Adding features to rpython that make it better as
a general-purpose programming language could actually make it *worse* as
a specialised language for building pypy.
OTOH, there does seem to be a growing interest in using rpython as a
stand-alone language. I've used it for some small projects and it
worked out great.
But the intersection of (people who want rpython as a general-purpose
language) and (people who have the ability to make that happen) seems to
be approximately zero at the moment...
With Unladen Swallow looking like a failed IT project, a year
behind schedule and not delivering anything like the promised
performance, Google management may pull the plug on funding.
Since there hasn't been a "quarterly release" in a year, that
may already have effectively happened.
All the schemes to speed up Python as defined by CPython seem to hit
a wall on speed improvement. Some of the numeric benchmarks go faster
on implementations that don't box all numbers, but 2x seems to be about
as good as it gets, even with a JIT compiler.
John Nagle
--
http://mail.python.org/mailman/listinfo/python-list
