Unfortunately for the run with n=11 Ackerman had consumed all the stack, but that can be solved with Stackless RPython.
Monday, January 28, 2008
RPython GCLB Benchmark - Recursive
Must admit that I am a big fan of python (the programming language), and when I saw the benchmark that RPython can be faster than C (on the binary tree benchmark from the Great Computer Language Shootout - GCLS), I just had to try RPython on another problem from GCLS, so I chose the one with worst performance compared to C/gcc (266 times slower) - recursive (with various recursive methods, e.g. Ackerman, Fibonacci and Tak). Results were roughly that rpython was 50-100 and gcc/c was 100-300 times faster than python (note: I only did one run, so numbers can be somewhat bogus, but not too bad I think).
Unfortunately for the run with n=11 Ackerman had consumed all the stack, but that can be solved with Stackless RPython.
Unfortunately for the run with n=11 Ackerman had consumed all the stack, but that can be solved with Stackless RPython.
Subscribe to:
Post Comments (Atom)
5 comments:
Interesting. It seems unlikely that RPython's garbage collector is to blame for the error for n=11, because all the actual computations don't really use any dynamically allocated memory (only the printing does). Which version of PyPy did you use? 1.0? Or the latest SVN?
I used the one from svn. Which version should I try with?
The one from SVN is perfect. I am amazed that RPython does so badly, the generated C should be very close to the manually written C code.
"Great Computer Language Shootout - GCLS"
It's called - The Computer Language
Benchmarks Game (benchmarks game).
Isaac, you are right, thanks :)
Post a Comment