Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PyPy: A Faster Python Implementation

pypy.org

Post reply on HN
Print view View original

11–20 of 25 posts

Re: PyPy: A Faster Python Implementation

#11

Post by shoo »

Rochus wrote: post #7

"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?

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

Re: PyPy: A Faster Python Implementation

#12

Post by Rochus »

shoo wrote: post #11
Rochus wrote: post #7

"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?

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.

Re: PyPy: A Faster Python Implementation

#13

Post by jashmatthews »

andrewl-hn wrote: post #3
pansa2 wrote: post #2

I’ve heard PyPy’s JIT described as “meta-tracing - instead of tracing your code, it traces itself as it interprets your code”. Is that accurate? What are the pros & cons of this approach compared to a normal tracing JIT, e.g. LuaJIT?

About 15 years ago there was a series of papers by Andreas Gal (then future and now former CTO of Mozilla) about precisely this aspect of JIT-compilers design. If you have a program and represent it as a series of VM instructions, and you try to jit them individually the kit compiler has very limited ability for optimization. Plus, after each such instruction the execution comes back to the piece of the interpreter t…

If you're interested in trace based compilation then the origins go much further back than Andreas Gal's work and into research in the 1970s into compilers for VLIW architectures [1]

It's not the dispatch to the next instruction that's expensive in most virtual machines. It's the sheer complexity of each instruction as it maps to the underlying assembly instructions [2]

Just getting rid of the dispatch loop doesn't help much and in many cases the increased pressure on the instruction cache makes performance worse.

I'm trying to help with this problem at the moment for the CRuby JIT compiler.

SpiderMonkey, LuaJIT and Dalvik record the trace in the bytecode interpreter. There's no generating baseline JITed code with additional trace recording stuff.

What PyPy does is quite different. PyPy is a Python virtual machine written in a language called RPython and has an interpreter and trace compiler for RPython.

It adds a whole layer of indirection compared to traditional trace compilers which makes it harder to do some optimizations but makes it easier to implement some more basic parts of trace recording and compilation and crucially, makes it somewhat re-usable for different languages.

[1] https://archive.org/details/optimizationofho00fish/mode/2up [2] https://www.sciencedirect.com/science/article/pii/S157106610...

Re: PyPy: A Faster Python Implementation

#15

Post by jashmatthews »

Rochus wrote: post #10
bjoli wrote: post #9

Earlier quoted context omitted.

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 be…

V8 became faster than LuaJIT quite some time ago now but LuaJIT is incredibly simple compared to V8.

Re: PyPy: A Faster Python Implementation

#16

Post by Rochus »

jashmatthews wrote: post #15
Rochus wrote: post #10

Earlier quoted context omitted.

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 be…

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).

Re: PyPy: A Faster Python Implementation

#17

Post by HoppyHaus »

PyPy is fantastic, it rescued a project I had where a massive amount of json needed to be parsed before an absurdly short heartbeat. Not even some of the fast json libraries could do it, but with a drop-in PyPy replacement, it worked, and still does, wonderfully

Re: PyPy: A Faster Python Implementation

#18

Post by traverseda »

jgwil2 wrote: post #14

What is stopping PyPy from getting more widespread adoption in the Python community? Surely it isn't that everyone is using the latest version of CPython; it's been years and many are still using 2.7.

The startup times are a fair bit worse, and the memory requirements are a fair bit higher. Despite everything else python does tend to be fast enough, and the worse startup/memory usage isn't necessarily worth it.

Also it doesn't speed up things that rely on external C libraries, so code using numpy/scipy/tensorflow/etc doesn't generally run appreciably faster.

Re: PyPy: A Faster Python Implementation

#19

Post by HoppyHaus »

jgwil2 wrote: post #14

What is stopping PyPy from getting more widespread adoption in the Python community? Surely it isn't that everyone is using the latest version of CPython; it's been years and many are still using 2.7.

If it hasnt changed, and I wasn't wrong in the first place, it has some issues with deep C integration, you need to jump over some hoops to get numpy working, and some of the other powerhouse libraries.

Re: PyPy: A Faster Python Implementation

#20

Post by jashmatthews »

Rochus wrote: post #16
jashmatthews wrote: post #15

Earlier quoted context omitted.

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

Post reply on HN