3 ms·

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

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.

sho_hn 11y ago
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.
- KingEllis 11y ago
  > 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.
  - sho_hn 11y ago
    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.
- valarauca1 11y ago
  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.
fijal 11y ago
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.
chrisseaton 11y ago
> 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 http://dl.acm.org/citation.cfm?id=1565827

sho_hn 11y ago

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.

KingEllis 11y ago
> 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.
- sho_hn 11y ago
  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.
valarauca1 11y ago
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.

fijal 11y ago

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.

chrisseaton 11y ago

> 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 http://dl.acm.org/citation.cfm?id=1565827