PyPy: A Faster Python Implementation
1–10 of 25 posts
Re: PyPy: A Faster Python Implementation
#2I’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?
Re: PyPy: A Faster Python Implementation
#3I’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 that selects the next instruction to execute: essentially a giant switch statement that makes branch prediction on CPU very difficult and inefficient.
The alternative is to not only jit the instructions but also embed pieces of the interpreter between them so that the compiler can see how those instructions are connected and generate the code for the whole sequence of them. This the compiler can make better assumptions about the code and optimize it a lot more.
This work eventually made it to all sorts of virtual machines. Adobe used it for Flash, Mozilla for their SpiderMonkey javascript engine, Google used this design for early versions of Android Dalvik VM.
PyPy uses it, too. That's why they call it a meta-compiler. It compiles pieces of your code and pieces of its own interpreter together to produce the more optimized binary.
Re: PyPy: A Faster Python Implementation
#4I love PyPy, just wish that they had more community love.
Re: PyPy: A Faster Python Implementation
#5pypy is great. what makes me sad is "they just stay behind cpython 1 or 2 versions"..
Re: PyPy: A Faster Python Implementation
#6pypy is great. what makes me sad is "they just stay behind cpython 1 or 2 versions"..
1-2 versions minor versions is pretty great. Most Linux distros that are deployed are the same!
Re: PyPy: A Faster Python Implementation
#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?
Re: PyPy: A Faster Python Implementation
#8Re: PyPy: A Faster Python Implementation
#9"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?
I suspect that the development effort that V8 has seen has been X orders of magnitude greater.
Re: PyPy: A Faster Python Implementation
#10"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?
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.