I have no detailed information. But the development of PyPy has been going on for 20 years and was partly sponsored by the EU. If you compare that with LuaJIT which was developed by a single person in a shorter timeframe and a performance even faster than V8 I would assume that maybe the conceptual approach taken by RPython/PyPy is less suited or Python is just that much harder to speedup. I would guess the former because also the performance of other RPython based implementations is not insanely impressive.
back
1 comments
V8 became faster than LuaJIT quite some time ago now but LuaJIT is incredibly simple compared to V8.
Are you sure? I did a cross-comparison recently and found LuaJIT still to be factor 1.3 to 1.5 faster than V8 in geometric mean (I used the Node.js implementation on the CLBG).
V8 8.0 is consistently faster than LuaJIT 2.1 on my machine even on heavily numeric benchmarks like Fannkuch or n-body.
Anything more realistic involving actual object access, not even allocation, and V8 wins by large margins.
time luajit-2.1.0-beta3 nbody.lua 50000000 real 0m8.437s
time node nbody.js 50000000 real 0m5.065s
I assume you would get another result running all CLBG algorithms and comparing the geometric means. I also run benchmarks including (hashed) table/field access and was virtually as fast as the same program when compiled natively, see https://github.com/rochus-keller/Oberon/blob/master/testcase.... Of course there are parts where LuaJIT 2.0 is slower than native, but there are also some opposite cases.