6 ms·

I am a big fan of automatically generating optimizing VMs from interpreters, like Graal (in this article) and also PyPy and others do. But the other approach, o

by azakai 2y ago

I am a big fan of automatically generating optimizing VMs from interpreters, like Graal (in this article) and also PyPy and others do. But the other approach, of writing a custom JIT for each language, seems much more flexible even if it is more dangerous and time-consuming. On small benchmarks I can believe the performance can be very similar between them, but I'd be more interested in large real-world codebases. I'm not aware of any myself, and can't seem to find any. Does anyone know?

darby_nine 2y ago
> But the other approach, of writing a custom JIT for each language, seems much more flexible even if it is more dangerous and time-consuming. This is also a good illustration of how we ended up with the NULL problem. I don't think it's as big of a deal in this case as interpreters/vms/compilers are designed to be fungible in ways that source code was not, but it's something worth thinking on.
almostgotcaught 2y ago
> and also PyPy this is a perpetually repeated misconception: > Why did we Abandon Partial Evaluation? 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... > others do to my knowledge graal is the only production project using futamura projections (what you're talking about)
- azakai 2y ago
  PyPy has experimented with multiple approaches here, yes, but as far as I know they did not abandon the overall approach of automatically converting an interpreter to an optimizing VM, which is what I mentioned. That's more general than partial evaluation (which is just one way to do such a conversion).
  - almostgotcaught 2y ago
    > automatically converting an interpreter to an optimizing VM but that is not what PyPy does > So, how did that tracing JIT generator work? A tracing JIT generates code by observing and logging the execution of the running program. This yields a straight-line trace of operations, which are then optimized and compiled into machine code. Of course most tracing systems mostly focus on tracing loops. > As we discovered, it's actually quite simple to apply a tracing JIT to a generic interpreter, by not tracing the execution of the user program directly, but by instead tracing the execution of the interpreter while it is running the user program (here's the paper we wrote about this approach). So it's just a tracing JIT but applied to the interpreter. One way to put it - it's effectively the same benefit as just running jython to begin with.
    - oasisaimlessly 2y ago
      The fact that they had to make up a new term for the technique (a "meta-tracing JIT") should be a hint that what they're doing is somewhat novel/unusual. If you read the paper[1] linked in your quote, you'd see that it is not "just a tracing JIT"; the interpreter being run under the JIT has some special hooks that let it tell the JIT e.g. where the program counter is: > Since the tracing JIT cannot know which parts of the language interpreter are the program counter, the author of the language interpreter needs to mark the relevant variables of the language interpreter with the help of a hint. The tracing interpreter will then effectively add the values of these variables to the position key. This means that the loop will only be considered to be closed if these variables that are making up the program counter at the language interpreter level are the same a second time. Loops found in this way are, by definition, user loops. This is vastly distinct from how Jython works. [1]: https://foss.heptapod.net/pypy/extradoc/-/blob/branch/extradoc/talk/icooolps2009/bolz-tracing-jit-final.pdf?ref_type=heads https://foss.heptapod.net/pypy/extradoc/-/blob/branch/extrad...
      - almostgotcaught 2y ago
        > The fact that they had to make up a new term for the technique (a "meta-tracing JIT") should be a hint that what they're doing is somewhat novel/unusual. you say this and then quote directly what the novelty is and so i ask you - does that piece warrant a whole new term? > This is vastly distinct from how Jython works. jython isn't doing anything - it's a python interpreter that runs on the jvm. my point was that that's the same thing: an interpreter for a language that itself is being jitted.
- metadat 2y ago
  Futamura projection refresher: https://en.wikipedia.org/wiki/Partial_evaluation https://en.wikipedia.org/wiki/Partial_evaluation Badass future space tech.
  - indolering 2y ago
    Does it involve robots that need to drink beer to function?
    - metadat 2y ago
      Definitely.. :)

by azakai 2y ago

darby_nine 2y ago

> But the other approach, of writing a custom JIT for each language, seems much more flexible even if it is more dangerous and time-consuming. This is also a good illustration of how we ended up with the NULL problem. I don't think it's as big of a deal in this case as interpreters/vms/compilers are designed to be fungible in ways that source code was not, but it's something worth thinking on.

almostgotcaught 2y ago

> and also PyPy this is a perpetually repeated misconception: > Why did we Abandon Partial Evaluation? 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... > others do to my knowledge graal is the only production project using futamura projections (what you're talking about)

azakai 2y ago
PyPy has experimented with multiple approaches here, yes, but as far as I know they did not abandon the overall approach of automatically converting an interpreter to an optimizing VM, which is what I mentioned. That's more general than partial evaluation (which is just one way to do such a conversion).
- almostgotcaught 2y ago
  > automatically converting an interpreter to an optimizing VM but that is not what PyPy does > So, how did that tracing JIT generator work? A tracing JIT generates code by observing and logging the execution of the running program. This yields a straight-line trace of operations, which are then optimized and compiled into machine code. Of course most tracing systems mostly focus on tracing loops. > As we discovered, it's actually quite simple to apply a tracing JIT to a generic interpreter, by not tracing the execution of the user program directly, but by instead tracing the execution of the interpreter while it is running the user program (here's the paper we wrote about this approach). So it's just a tracing JIT but applied to the interpreter. One way to put it - it's effectively the same benefit as just running jython to begin with.
  - oasisaimlessly 2y ago
    The fact that they had to make up a new term for the technique (a "meta-tracing JIT") should be a hint that what they're doing is somewhat novel/unusual. If you read the paper[1] linked in your quote, you'd see that it is not "just a tracing JIT"; the interpreter being run under the JIT has some special hooks that let it tell the JIT e.g. where the program counter is: > Since the tracing JIT cannot know which parts of the language interpreter are the program counter, the author of the language interpreter needs to mark the relevant variables of the language interpreter with the help of a hint. The tracing interpreter will then effectively add the values of these variables to the position key. This means that the loop will only be considered to be closed if these variables that are making up the program counter at the language interpreter level are the same a second time. Loops found in this way are, by definition, user loops. This is vastly distinct from how Jython works. [1]: https://foss.heptapod.net/pypy/extradoc/-/blob/branch/extradoc/talk/icooolps2009/bolz-tracing-jit-final.pdf?ref_type=heads https://foss.heptapod.net/pypy/extradoc/-/blob/branch/extrad...
    - almostgotcaught 2y ago
      > The fact that they had to make up a new term for the technique (a "meta-tracing JIT") should be a hint that what they're doing is somewhat novel/unusual. you say this and then quote directly what the novelty is and so i ask you - does that piece warrant a whole new term? > This is vastly distinct from how Jython works. jython isn't doing anything - it's a python interpreter that runs on the jvm. my point was that that's the same thing: an interpreter for a language that itself is being jitted.
metadat 2y ago
Futamura projection refresher: https://en.wikipedia.org/wiki/Partial_evaluation https://en.wikipedia.org/wiki/Partial_evaluation Badass future space tech.
- indolering 2y ago
  Does it involve robots that need to drink beer to function?
  - metadat 2y ago
    Definitely.. :)