5 ms·

misleading title - both RPython and Truffle/Graal are not interpeters but JIT compilers instead - the connection with interpretation is that they offer (or clai

by tomp 3y ago

misleading title - both RPython and Truffle/Graal are not interpeters but JIT compilers instead - the connection with interpretation is that they offer (or claim to) automatic construction of a JIT compiler if the user writes an interpreter.

duped 3y ago
Related: the Futamura projections https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_projections https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_pr...
- rightbyte 3y ago
  Ye well my head went spinning reading that. Does such a "compiler factory" exist?
  - duped 3y ago
    Yes, this is what Truffle is all about (1). You use Truffle to write the AST interpreter for your language and then GraalVM uses it to compile a JIT compiler for you automatically, with the bonus of interop with other languages. (1) https://www.graalvm.org/latest/graalvm-as-a-platform/language-implementation-framework/HostOptimization/ https://www.graalvm.org/latest/graalvm-as-a-platform/languag...
    - mikmoila 3y ago
      Wasn't it so that as Graal jitter is written in Java, Truffle can easily call it by using ordinary Java api? By the way there's an excellent series of articles about implementing an interpreter with Truffle by Adam Ruka: https://www.endoflineblog.com/graal-truffle-tutorial-part-12-classes-1-methods-new https://www.endoflineblog.com/graal-truffle-tutorial-part-12...
- mikmoila 3y ago
  Good point, isn't this the partial compilation?
RetroTechie 3y ago
Not only that: It uses some custom language (SOM), built the AST/bytecode interpreters for that on top of other systems (GraalVM and RPython) which prohibits some optimizations and may use some intermediate format (Graal IR). And then compares results using a limited set of benchmarks (Are We Fast Yet). Interesting, but all in all it's not saying much (imho). As so often: devil is in the details.
- Twirrim 3y ago
  A research field specific language based off a subset of smalltalk, that has been used for research in to just this kind of work for over two decades. It's not like the author went and chose or created something random. They used what folks in their field use. https://som-st.github.io/ https://som-st.github.io/
- masklinn 3y ago
  > It uses some custom language (SOM), built the AST/bytecode interpreters SOM is the language being implemented, it's not used to build the interpreters.
- smarr 3y ago
  With the amount of work that's needed to even attempt such a study and get to a point that one can precisely define which variable one is actually measuring, there are indeed compromises needed. But please feel free to replicate the study for your preferred language. I am happy to discuss more about why we made certain choices.
masklinn 3y ago
> misleading title Definitely. The title of the linked paper is a lot more reasonable: > AST vs. Bytecode: Interpreters in the Age of Meta-Compilation it's a shame the author decided to go with a clickbait version for his blog entry.
nirvdrum 3y ago
Graal is a JIT compiler. Truffle is a framework/DSL for building self-optimizing AST interpreters. Truffle also provides a partial evaluator that works with Graal for the metacompilation part. However, any interpreter you build with Truffle will run fine on any JVM. It'll be pretty slow without Graal, but it's a functional AST interpreter all the same. You could even use Native Image to AOT compile it to native code and cut the JVM out if you wanted.
smarr 3y ago
Please see Figure 2 in the blog post https://stefan-marr.de/2023/10/ast-vs-bytecode-interpreters/#fig-interp-perf https://stefan-marr.de/2023/10/ast-vs-bytecode-interpreters/... or Sec. 5.2 in the paper https://stefan-marr.de/papers/oopsla-larose-et-al-ast-vs-bytecode-interpreters-in-the-age-of-meta-compilation/#x1-390005.2 https://stefan-marr.de/papers/oopsla-larose-et-al-ast-vs-byt... We report on results for both, with and without just-in-time compilation. The specific focus for this work was pure interpreter performance in the context of metacompilation systems, but before compilation had a chance to kick in. For both RPython and Truffle/Graal, it's possible to disable the JIT compilers and measure pure interpreter speed.
- tomp 3y ago
  Thanks for the clarification! So the "baseline" is Java - is that Java compiled or interpreted? And if the latter, is the non-JIT-ted Graal interpreter compiled (as Java) and interpreting the script, or is it interpreted itself?
  - smarr 3y ago
    > is that Java compiled or interpreted? The figure for the JIT-compiled numbers uses a standard HotSpot JVM, with JIT compilation. The figures for the interpreter numbers uses a standard HotSpot JVM with the -Xint flag, so, only using the Java bytecode interpreter. The TruffleSOM interpreter is AOT-compiled, so, it's a native binary, which is then interpreting the SOM code.

by tomp 3y ago

duped 3y ago

Related: the Futamura projections https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_projections https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_pr...

rightbyte 3y ago
Ye well my head went spinning reading that. Does such a "compiler factory" exist?
- duped 3y ago
  Yes, this is what Truffle is all about (1). You use Truffle to write the AST interpreter for your language and then GraalVM uses it to compile a JIT compiler for you automatically, with the bonus of interop with other languages. (1) https://www.graalvm.org/latest/graalvm-as-a-platform/language-implementation-framework/HostOptimization/ https://www.graalvm.org/latest/graalvm-as-a-platform/languag...
  - mikmoila 3y ago
    Wasn't it so that as Graal jitter is written in Java, Truffle can easily call it by using ordinary Java api? By the way there's an excellent series of articles about implementing an interpreter with Truffle by Adam Ruka: https://www.endoflineblog.com/graal-truffle-tutorial-part-12-classes-1-methods-new https://www.endoflineblog.com/graal-truffle-tutorial-part-12...
mikmoila 3y ago
Good point, isn't this the partial compilation?

RetroTechie 3y ago

Not only that: It uses some custom language (SOM), built the AST/bytecode interpreters for that on top of other systems (GraalVM and RPython) which prohibits some optimizations and may use some intermediate format (Graal IR). And then compares results using a limited set of benchmarks (Are We Fast Yet). Interesting, but all in all it's not saying much (imho). As so often: devil is in the details.

Twirrim 3y ago
A research field specific language based off a subset of smalltalk, that has been used for research in to just this kind of work for over two decades. It's not like the author went and chose or created something random. They used what folks in their field use. https://som-st.github.io/ https://som-st.github.io/
masklinn 3y ago
> It uses some custom language (SOM), built the AST/bytecode interpreters SOM is the language being implemented, it's not used to build the interpreters.
smarr 3y ago
With the amount of work that's needed to even attempt such a study and get to a point that one can precisely define which variable one is actually measuring, there are indeed compromises needed. But please feel free to replicate the study for your preferred language. I am happy to discuss more about why we made certain choices.

masklinn 3y ago

> misleading title Definitely. The title of the linked paper is a lot more reasonable: > AST vs. Bytecode: Interpreters in the Age of Meta-Compilation it's a shame the author decided to go with a clickbait version for his blog entry.

nirvdrum 3y ago

Graal is a JIT compiler. Truffle is a framework/DSL for building self-optimizing AST interpreters. Truffle also provides a partial evaluator that works with Graal for the metacompilation part. However, any interpreter you build with Truffle will run fine on any JVM. It'll be pretty slow without Graal, but it's a functional AST interpreter all the same. You could even use Native Image to AOT compile it to native code and cut the JVM out if you wanted.

smarr 3y ago

Please see Figure 2 in the blog post https://stefan-marr.de/2023/10/ast-vs-bytecode-interpreters/#fig-interp-perf https://stefan-marr.de/2023/10/ast-vs-bytecode-interpreters/... or Sec. 5.2 in the paper https://stefan-marr.de/papers/oopsla-larose-et-al-ast-vs-bytecode-interpreters-in-the-age-of-meta-compilation/#x1-390005.2 https://stefan-marr.de/papers/oopsla-larose-et-al-ast-vs-byt... We report on results for both, with and without just-in-time compilation. The specific focus for this work was pure interpreter performance in the context of metacompilation systems, but before compilation had a chance to kick in. For both RPython and Truffle/Graal, it's possible to disable the JIT compilers and measure pure interpreter speed.

tomp 3y ago
Thanks for the clarification! So the "baseline" is Java - is that Java compiled or interpreted? And if the latter, is the non-JIT-ted Graal interpreter compiled (as Java) and interpreting the script, or is it interpreted itself?
- smarr 3y ago
  > is that Java compiled or interpreted? The figure for the JIT-compiled numbers uses a standard HotSpot JVM, with JIT compilation. The figures for the interpreter numbers uses a standard HotSpot JVM with the -Xint flag, so, only using the Java bytecode interpreter. The TruffleSOM interpreter is AOT-compiled, so, it's a native binary, which is then interpreting the SOM code.