Hacker News Reader

Comment by maxerickson | Hacker News Reader

The novelty is that the JIT is produced by compiling a simple interpreter.

http://morepypy.blogspot.com/2011/04/tutorial-writing-interp...

Others have shown up and take the same approach, Graal and Zippy for example.

I've never heard of those. Python on the other hand has been my primary professional language for years. i.e. people pay me to program in python.

See how PyPy might be a tinsy bit more relevant / meaningful to professional developers.

Java developers know them quite well. In fact Java 9 is getting a plugin API for Graal.

I still don't see the novelty.

Its a JIT compiler run-time. You put a program in the JIT-compiler's run-time. And it was JIT compiled. The program you gave it just so happens to have Turning Complete behavior. It doesn't change anything the JIT compiler is doing.

It's like a compiler boot-strapping itself. It seems really impressive, but really the program is just doing its job on an input. The input just happens to be itself.

It's not about novelty, it's about realization. PyPy exists and works as both an open source project and as a codebase, which is no easier to achieve than coming up with an idea. That said, PyPy has yet to demonstrate real impact outside the Python community, and projects with a somewhat similar aim to what's being discussed (the Parrot VM) have likewise not gotten to significant uptake. We'll see. PyPy is definitely already useful at other things, though.

> PyPy exists and works as both an open source project and as a codebase, which is no easier to achieve than coming up with an idea.

I have no idea what you are getting at here.

The post I was replying to was misunderstanding "this is new!" as "this is the first time this exists!" when it's more about "this is the first time this is available!", where availability is complex and defined by factors like governance, distribution, quality, accessibility, infrastructure, communication ... these are the things that tend to be make or break long after novelty had its moment.

Whether "this is the first time this is available!" is true or not is open to debate (it depends in part on how you weigh the listed concerns), but parent's post didn't read on it.

So you just adding a user program to a REPL/Parser and cramming it into a JIT?

You can do this in Javascript, or LLVM-IR just as easily.

The main blessing is also its biggest curse. You are writing a language to move fast, and change often. Its a good learning tool, but a constantly changing language is next to impossible to build value upon.

Did you actually look at the blog post? The novelty is the idea that you generate a JIT compiler from the interpreter using a few hints. Truffle does that, but Truffle is newer than PyPy.

> I still don't see the novelty.

Are you familiar of the state of the art in JIT compilers at the time PyPy's JIT was developed? It was absolutely a novel idea at the time, and was published as a novel result in a peer-reviewed paper. I'm not sure how else to convince you of that.

> However, applying an unmodified tracing JIT to a program that is itself a bytecode interpreter results in very limited or no speedup. In this paper we show how to guide tracing JIT compilers to greatly improve the speed of bytecode interpreters. One crucial point is to unroll the bytecode dispatch loop, based on two kinds of hints provided by the implementer of the bytecode interpreter.

> Applying a trace-based optimizer to an interpreter and adding hints to help the tracer produce better results has been tried before in the context of the DynamoRIO project [27], which has been a great inspiration for our work. They achieve the same unrolling of the interpreter loop so that the unrolled version corresponds to the loops in the user pro- gram. However the approach is greatly hindered by the fact that they trace on the machine code level and thus have no high-level information available about the interpreter. This makes it necessary to add quite a large number of hints, be- cause at the assembler level it is not really visible anymore that e.g., a bytecode string is immutable. Also more ad- vanced optimizations like allocation removal would not be possible with that approach.

http://dl.acm.org/citation.cfm?id=1565827

Reply on news.ycombinator.com