11 ms·
This is the first time I've learned of this. How it compares to PyPy [1]: > PyPy is an implementation of Python with its own JIT. The biggest difference compar
by y7 5y ago
This is the first time I've learned of this. How it compares to PyPy [1]:
> PyPy is an implementation of Python with its own JIT. The biggest difference compared to Pyjion is that PyPy doesn't support all C extension modules without modification unless they use CFFI or work with the select subset of CPython's C API that PyPy does support. Pyjion also aims to support many JIT compilers while PyPy only supports their custom JIT compiler.
Apparently it's originally a Microsoft project, and it requires .NET. The project already exists for a few years, but it looks like they've gained net performance improvements over CPython only the past few months [2].
[1] https://github.com/tonybaloney/Pyjion https://github.com/tonybaloney/Pyjion
[2] https://github.com/tonybaloney/Pyjion/issues/198 https://github.com/tonybaloney/Pyjion/issues/198
- johnnycerberus 5y agoIsn't this what the GraalVM [1] guys are also trying to do? Seems like today the competition is between who is more polyglot than the other, JVM, CLR or WASM. [1] https://github.com/oracle/graalpython https://github.com/oracle/graalpython
- chrisseaton 5y agoA big difference is the Pyjion generates .NET compiler IR manually, while GraalVM generates Graal compiler IR automatically through partial evaluation of a declarative specification of an interpreter specialised to the program (the first Futamura Projection.) In my opinion that's far more powerful in terms of removing abstraction. But Pyjion also seems like a very cool project.
- rowanG077 5y agoDamn I didn't know any of the Futamura Projections where actually implemented in practice.
- chrisseaton 5y agohttps://chrisseaton.com/truffleruby/pldi17-truffle/pldi17-truffle.pdf https://chrisseaton.com/truffleruby/pldi17-truffle/pldi17-tr...
- jhgb 5y agoSounds to me like PyPy has been using Futamura projections for a decade or so.
- rowanG077 5y agoCan you link me to some sources? I'm not familiar with PyPy but I thought it's a normal tracing JIT. In fact quick googling shows a blog post explicitly saying PyPy does NOT use PE: https://www.pypy.org/posts/2018/09/the-first-15-years-of-pypy-3412615975376972020.html#why-did-we-abandon-partial-evaluation https://www.pypy.org/posts/2018/09/the-first-15-years-of-pyp.... Besides not every PE instance is a Futurama Projection.
- svieira 5y agoPyPy is two projects. 1. RPython + the PyPy _compiler_ which is a compiler for JIT compilers (like GraalVM as I understand it) 2. An implementation of the Python language _using_ RPython to produce a JIT for Python scripts. There are other languages _using_ RPython + PyPy compiler to produce JIT compilers for languages other than Python too. https://doc.pypy.org/en/latest/architecture.html#layers https://doc.pypy.org/en/latest/architecture.html#layers
- rowanG077 5y agoI see. This doesn't look like a Futaruma Projection to me. What PyPy does is run a python program under their own RPython based interpreter. Then it uses a tracing JIT to JIT the RPython based interpreter. There is no PE going on. No residual specialized program is created. The first Futaruma Projection would be if PyPy would specialize the interpreter based on the python program yielding an executable.
- pjmlp 5y agoWASM isn't on the same league until it offers GC support.