Related: the Futamura projections

https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_pr...

Ye well my head went spinning reading that. Does such a "compiler factory" exist?

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/languag...

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...

Good point, isn't this the partial compilation?

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.

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/

> 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.

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.

> 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.

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.

Please see Figure 2 in the blog post 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-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.

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?

> 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.