3 ms·

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 interpre

by 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.
    - oasisaimlessly 2y ago
      > does that piece warrant a whole new term? In my opinion: Yes, definitely! Without meta-tracing techniques, a JIT'd interpreter can only hope to be on par with a compiled interpreter, never significantly faster. It will never go beyond the limitations of an interpreter, because the JIT can't "see" the user code that the interpreter is running.
- azakai 2y ago
  I'm not familiar enough with Jython, but I do consider applying a tracing JIT to an interpreter as a way to automatically convert an interpreter to an optimizing VM. I suppose if the tracing JIT were very complex and very tailored to a single language that might not make sense, but my impression of PyPy is that the opposite is true, and PyPy can in fact run other languages than Python.
  - almostgotcaught 2y ago
    > but I do consider applying a tracing JIT to an interpreter as a way to automatically convert an interpreter to an optimizing VM. there's nothing automatic about it. the user above you quoted from their paper - the user (person writing the interpreter) must annotate their code to pass hints to the tracing jit.
    - azakai 2y ago
      It is still largely automatic. Some amount of special annotations are needed in all these related approaches. For example, in this article, @CompilationFinal is used in Graal interpreters. (It is possible more annotations are needed in PyPy than Graal, but still, an annotated interpreter is far, far simpler than writing an optimizing JIT!)

by azakai 2y ago

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.
  - oasisaimlessly 2y ago
    > does that piece warrant a whole new term? In my opinion: Yes, definitely! Without meta-tracing techniques, a JIT'd interpreter can only hope to be on par with a compiled interpreter, never significantly faster. It will never go beyond the limitations of an interpreter, because the JIT can't "see" the user code that the interpreter is running.
azakai 2y ago
I'm not familiar enough with Jython, but I do consider applying a tracing JIT to an interpreter as a way to automatically convert an interpreter to an optimizing VM. I suppose if the tracing JIT were very complex and very tailored to a single language that might not make sense, but my impression of PyPy is that the opposite is true, and PyPy can in fact run other languages than Python.
- almostgotcaught 2y ago
  > but I do consider applying a tracing JIT to an interpreter as a way to automatically convert an interpreter to an optimizing VM. there's nothing automatic about it. the user above you quoted from their paper - the user (person writing the interpreter) must annotate their code to pass hints to the tracing jit.
  - azakai 2y ago
    It is still largely automatic. Some amount of special annotations are needed in all these related approaches. For example, in this article, @CompilationFinal is used in Graal interpreters. (It is possible more annotations are needed in PyPy than Graal, but still, an annotated interpreter is far, far simpler than writing an optimizing JIT!)