So, here we go:
| Language: | Time of run (for N=14): |
| Python version running on Python 2.5.1, distribution | 25.5s |
| Python version running on PyPy with generational GC | 45.5 |
| Python with psyco | 20s |
| RPython translated to C using PyPy's generational GC | 0.42s |
| compiling the Haskell version with GHC 6.6.1 | 1.6s |
| compiling the C version with gcc 4.1.2 -O3 -fomit-frame-pointer | 0.6s |
Also worth noticing is that when using psyco with the original version (with tuples) it is very fast (2s).
So, PyPy's Python interpreter is 80% slower than CPython on this (not too horrible), but RPython is 40% faster than gcc here. Cool. The result is mostly due to our GC, which also proves that manual memory-management can be slower than garbage collection in some situations. Please note that this result does not mean that RPython is meant for you. It requires a completely different mindset than the one used to program in Python. Don't say you weren't warned! :-)
15 comments:
"It requires a completely different mindset than the one used to program in Python."
Can you elaborate? "RPython for Python programmers" would be an excellent addition to the docs or this blog. :)
I agree with Jonathan. There are many Python programmers who would *love* to be able to write Python extensions with RPython.
I know that this is already possible, but there are two issues:
* Lack of documentation on programming with RPython (I realise that this is a moving target)
* Last I heard, the refcounting implementation made RPython extensions inefficient
If these two issues were resolved (or mostly resolved) then a lot more people might start using the PyPy toolchain.
Asides from my growsing, it looks like PyPy is becoming more impressive by the day. Congratulations.
As of today you can't write CPython extensions in RPython.
Why not ask for the great computer language shootout to include RPython as one of their benchmarking languages? This could be a good and free advertising for the pypy project.
mmm
0.42
42
The answer...
Hi Michael,
Leonardo is correct, the extension compiler was removed from SVN in November. We had many discussions about this step, but eventually it turned out to be necessary for many reasons. The extcompiler never was that useful in the first place because the produced extensions weren't fast (one of the reasons being the bad refcounting indeed).
The other reasons were that the extcompiler was impossible to maintain and was actually preventing progress, because it kept code alive that we wanted to get rid off.
So at the moment you cannot use PyPy any more to produce CPython extensions, only standalone programs.
It's completely possible that the extcompiler will be reborn in the future, but at the moment our priorities are really to make PyPy a good Python and not do tons of things on the side.
Cheers,
Carl Friedrich
I would also say nowadays it's already possible to write extension modules in RPython... but just for PyPy, now for CPython :-).
Jokes apart, if someone is really interested in writing part of its application in RPython (despite our warnings :-)), targeting PyPy could be an interesting alternative, as long as you don't need external libraries and the speed gain is more than what you loose in other areas where PyPy is actually slower.
I think a lot of people are interested in using RPython for performance reasons. But about nobody will leave CPython atm, because extension modules are not working.
At the moment, I wouldn't leave CPython since all I am doing is heavily based on scipy. And so my only option is (a) to wait PyPy being able to compile extensions for CPython or (b) PyPy making use of CPython extensions.
As long as this is not going to happen, I probably will not use RPython for serious projects. :/
"Also the benchmark is very likely flawed because it favours better GCs :)"
Why would that be a flaw? Note: this is an adaptation of a benchmark for testing GC
Leonardo Santagada said "Why not ask for the great computer language shootout to include RPython ..."
FAQ Why don't you include language X?
Once the RPython was translated to C by PyPy how did you compile the C?
> Why would that be a flaw? Note: this is an adaptation of a benchmark for testing GC
I know, but I realised it after posting :) (We even have original somewhere around to compare gcs). Also, honestly a lot of python versions rely on libraries written in C, hence it took me a while that is "pure enough".
> Once the RPython was translated to C by PyPy how did you compile the C?
With the very same options as bare gcc. -O3 -fomit-frame-pointer
Did you try any of the other computer language shootout benchmarks?
More objects != OO.
Perhaps you meant to say that it more closely reflects the domain?
No, I don't know how I ended up on this blog post.
How does RPython compare to Python Shedskin?
"Can you elaborate? "RPython for Python programmers" would be an excellent addition to the docs or this blog. :)"
+1 on this.
Greetings from Brazil!
Post a Comment