1. PyPy's Python interpreter is written in RPython, a subset of Python.
2. CPython is an interpreter written in C.
3. When compiled into a JIT, PyPy's Python interpreter is now generally faster than CPython, sometimes by a wide margin.
4. Code written in RPython is faster than code written for a nearly identical purpose in C. The C code in question has been the target of aggressive optimizations for years while the RPython code is relatively immature.
Now, for many applications I'm sure C remains faster than RPython. But for the application RPython is designed for--writing an interpreter for a dynamic language--I think it is safe to say that RPython appears faster than C.
The fact that the PyPy's interpreter is cleaner, safer, and more maintainable than equivalent C code is also a huge win. Again, the point of the original post is that RPython could become an simple implementation language to create fast interpreters for dynamic languages. It could also become a target language for other compilers.
Anyways, as others have pointed out, Lua is a considerably simpler language than Python. LuaJIT is a really remarkable piece of engineering, especially since it was written by one guy, but it's really a completely different project than PyPy. Its aim is to make Lua--and only Lua--extremely fast. If PyPy's Python implementation gets no faster (which I think is unlikely) the potential ability to easily create new dynamic languages that are similarly speedy is itself an amazing achievement.
> 4. Code written in RPython is faster than code written for a nearly identical purpose in C.
This is where your argument falls down. Selection sort and heap sort are both written for the identical purpose, but due to their different designs and different complexities, a heap sort written in ordinary Python would outperform a selection sort written in C for a great many inputs. This does not prove that Python is faster than C, it simply proves that two programs, even written for the identical purpose, can achieve that purpose in vastly different ways, and those differences can greatly impact the performance of those programs.
I find it interesting that people say Lua is a "simple" language, as if that's a flaw. Also, simple in which respect? To optimise? To parse?
Note that this is no fanboyism. It's just that these performance claims are mostly phony anyways. How much % of general python code is in RPython?
It's good to see this kind of progress, for both python and lua, as it opens up room for dynamic languages in new areas and helps to change the mindset of some people. However, this picking on each other is more than expendable IMHO..
I don't think anybody is picking on each others. The two projects are way too different to be compared IMHO.
Also being simple isn't a flaw in my mind. Lua is quite a beautiful language. And theoretically much more closer to my likings than python. However, for practical programming, i prefer python, just because it's a 'good enough', very comfortable to work with language that has a ton of useful and well done libraries. This isn't the case of lua, probably because it's purpose isn't to be used as a general language, but to be a real scripting language to be embedded in bigger applications.
1. PyPy's Python interpreter is written in RPython, a subset of Python.
2. CPython is an interpreter written in C.
3. When compiled into a JIT, PyPy's Python interpreter is now generally faster than CPython, sometimes by a wide margin.
4. Code written in RPython is faster than code written for a nearly identical purpose in C. The C code in question has been the target of aggressive optimizations for years while the RPython code is relatively immature.
Now, for many applications I'm sure C remains faster than RPython. But for the application RPython is designed for--writing an interpreter for a dynamic language--I think it is safe to say that RPython appears faster than C.
The fact that the PyPy's interpreter is cleaner, safer, and more maintainable than equivalent C code is also a huge win. Again, the point of the original post is that RPython could become an simple implementation language to create fast interpreters for dynamic languages. It could also become a target language for other compilers.
Anyways, as others have pointed out, Lua is a considerably simpler language than Python. LuaJIT is a really remarkable piece of engineering, especially since it was written by one guy, but it's really a completely different project than PyPy. Its aim is to make Lua--and only Lua--extremely fast. If PyPy's Python implementation gets no faster (which I think is unlikely) the potential ability to easily create new dynamic languages that are similarly speedy is itself an amazing achievement.