4 ms·
I suspect that the development effort that V8 has seen has been X orders of magnitude greater.
by bjoli 6y ago
I suspect that the development effort that V8 has seen has been X orders of magnitude greater.
- Rochus 6y agoI 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.
- jashmatthews 6y agoV8 became faster than LuaJIT quite some time ago now but LuaJIT is incredibly simple compared to V8.
- Rochus 6y agoAre 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).
- jashmatthews 6y agoV8 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
- Rochus 6y agoI 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/testcases/Hennessy_Results 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.