Item — HN Reader

"The geometric average of all benchmarks is 0.23 or 4.3 times faster than cpython" (see https://speed.pypy.org/)

If we put this figure in context with the CLBG (see https://benchmarksgame-team.pages.debian.net/benchmarksgame/...) we're somewhere between Racket and Dart.

Is a further speedup to be expected? Why is it still slower than V8 after so much development effort?

2 comments

I suspect that the development effort that V8 has seen has been X orders of magnitude greater.

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.

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.

Lots of discussion about obstacles to speeding up python in older threads, e.g. https://news.ycombinator.com/item?id=12025309

Thanks for the link. Had a quick look at the top rated comment, but "Python spends almost all of its time in the C runtime - This means that it doesn't really matter how quickly you execute the 'Python' part of Python" is already wrong. CPython is an interpreter, and this interpreter is implemented in C. You cannot argument that due to the fact that the runtime spends most of its time in C functions it makes no sense to improve it. That's exactly what a JIT (in contrast to an interpreter) is for.

Over in #guile on freenode we just hit a bump where string-for-each on a string was a lot slower than (for-each proc (string->list lst)) due to a costly jump into C from the jitted code. Rewriting string-for-each in scheme solved the problem.

I don't know what I wanted to say with that, but I know pypy has spent a lot of time rewriting some core libraries in python/Rpython. I thought it was to make pypy more hackable, but maybe it has some jit benefits as well.