Skip to content
Hallway
0:00 / 0:00

#interpreters#starlark#neilmitchell

Cheaply writing a fast interpreter - Neil Mitchell

Performance Summit

2K subscribers • 1 video on Hallway

YouTube
  • Recommended by 2 people: 1 on Lobsters and 1 in engineering communities.
  • Presented by Neil Mitchell

Intermediate. Assumes working knowledge.

8.9K views5 years ago2 recommendations

Systems programmingProgramming languagesCompilers and interpretersPerformance and optimizationPython

Neil Mitchell explores techniques for implementing interpreters efficiently, comparing AST interpretation, bytecode, and closure generation using Starlark.

For dynamic languages, there are well known approaches to achieve maximum performance, e.g. JIT. But such approaches are often very expensive to implement and maintain. In this talk we'll look at ways of implementing interpreters for less frequently used languages, which necessarily trade off performance vs implementation effort. As an example, we will consider the Starlark configuration language, a deterministic subset of Python used by the build systems Buck and Bazel. We'll cover techniques such direct AST interpretation, bytecode, closure generation - comparing the effort and performance of each approach. London Performance Summit 2nd edition @perfsummit1 #londonperfsummit

Why it's here

2 people recommend this

What people say. Recommended for its surprising insights into the relative performance of different interpreter implementations.

u/celeritasCeleryin r/ProgrammingLanguages • Recommends

Relative performance of interpreter implementations I have been learning more about interpreters and trying to build a mental framework of the trade-offs when implementing them. I was watching this youtube video comparing different interpreter backends for a build configuration language. The whole talk is very interesting, but there some things that I found very surprising. One is that their register based interpreter is massively faster then their stack based interpreter (over 3.5x better performance, almost as fast as native rust). The only reference point I have for this is this paper on lua 5 which shows a best case 2x speed up with register based vm (which is still sizeable). *why i…
22View on Reddit

lorddimwiton Lobsters • Recommends

Cheaply writing a fast interpreter
11View on Lobsters

u/mamcxin r/ProgrammingLanguages • Mentions

On “Orion, a purely functionnal Lisp written in Rust.”

A full bytecode is not the only way to speed up: https://blog.cloudflare.com/building-fast-interpreters-in-rust/ and here a comparison between different ways: [video In short, doing a light version of futamura projections (aka: compile to closures) can beat a naive bytecode compiler with much less complexity.
6View on Reddit

u/mamcxin r/ProgrammingLanguages • Mentions

On “Writing a Register Based VM”

This video (Rust, but applicable) could give you some insights in why the speed up could not be as large: [video Also check this, it unpack in batches of 4 instructions (like when you know its comming + 1 2): https://github.com/3c1u/bf-rs/blob/master/src/codegen.rs Kind of clever, actually.
3View on Reddit

u/mamcxin r/ProgrammingLanguages • Mentions

On “Big update to Enso 2.0 - a textual/visual programming language.”

>Then how can JIT be ok? It completely bypasses the interpreter. No. JIT is part of the toolset of an interpreter (check [video What is confusing is that your interpreter loop and your functions call are not necessarily made to be the same thing. Let me show you an example: def sum_bench(n): acc = 0 for i in range(1, n) acc += i return acc Using a compiler pass/optimization is possible to turn the above code into: def sum_bench(n): return sum(range(1, n)) But is *NOT the same* to IMPLEMENT sum in C (or the host language)! JITs turn AST into machine code (similar how compilers do, only that at runtime). But both COULD import functionality from elsewher…
2View on Reddit

u/mamcxin r/ProgrammingLanguages • Mentions

On “Wondering about design decisions”

This is my actual copy-paste answer about this: * https://blog.cloudflare.com/building-fast-interpreters-in-rust/ * "Cheaply writing a fast interpreter (slides)" or [video (This one specially do a comparision) Also, even without going crazy like above, a question of mine years ago: * How can be an interpreter faster than C (aka: kdb+) So, you can go faster with an interpreter than many thought (at first). \--- I'm building an interpreter for my lang and making the parser and the type checking has been more challenging than that. By a lot (my progress looks like is frozen in time with not much activity, but in fact, I have been working!). So, save time and go for an interpreter. The…
2View on Reddit

u/everything-narrativein r/ProgrammingLanguages • Mentions

On “April 2022 monthly "What are you working on?" thread”

I'm working on a "smalltalk family" (in OO-semantics, not syntax) language I'm tentatively calling aloxtalk (yes, the logo is going to be an axolotl.) I recently came across Vale's memory management model of generational reference counting and I'm working on implementing it first as a Rust library, then using said library for aloxtalk's memory model, which will make the language very Rust-y (hence ALuminium OXide.) Other than that I'm planning some sneaky things with thread-safety, RAII, first-class patterns, and a Ruby dialect syntax. Rather than implement an actual byte code interpreter, I plan on just compiling the AST to Rust closures as in this talk. It's going to have some _really…
2View on Reddit

u/mamcxin r/ProgrammingLanguages • Mentions

On “Does it make sense to write an interpreter in a non-GC programming language (like Rust or C)?”

You will enjoy this talk that show the different ways you can implement an interpreter: [video P.D: The easiest by far with good performance is to "compile into lambdas".
1View on Reddit