Live data from Hacker News

Building the fastest Lua interpreter automatically

sillycross.github.io

31–40 of 114 posts

Re: Building the fastest Lua interpreter automatically

#31
> With the tail-call approach, each bytecode now gets its own function, and the pathological case for the C/C++ compiler is gone. And as shown by the experience of the Google protobuf developers, the tail-call approach can indeed be used to build very good interpreters. But can it push to the limit of hand-written assembly interpreters? Unfortunately, the answer is still no, at least at its current state.

> The main blockade to the tail-call approach is the callee-saved registers. Since each bytecode function is still a function, it is required to abide to the calling convention, specifically, every callee-saved register must retain its old value at function exit.

This is correct, wasting of callee-saved registers is a shortcoming of the approach I published about protobuf parsing (linked from the first paragraph above). More recently I have been experimenting with a new calling convention that uses no callee-saved registers to work around this, but the results so far are inconclusive. The new calling convention would use all registers for arguments, but allocate registers in the opposite order of normal functions, to reduce the chance of overlap. I have been calling this calling convention "reverse_cc".

I need to spend some time reading this article in more detail, to more fully understand this new work. I would like to know if a new calling convention in Clang would have the same performance benefits, or if Deegen is able to perform optimizations that go beyond this. Inline caching seems like a higher-level technique that operates above the level of individual opcode dispatch, and therefore somewhat orthogonal.

Re: Building the fastest Lua interpreter automatically

#35

> The problem with the “big switch-case” approach is that C/C++ compilers simply cannot handle such code well. Is this the case with Rust?

Most likely, as the pathological behavior the article mentions is mostly around register allocation and Rust uses LLVM.

Re: Building the fastest Lua interpreter automatically

#36

> Lua is concise yet supports almost every language feature one can find in dynamic languages Having yet another terrible package manager? A non-existent ecosystem outside of checks notes game scripting and nginx? Reinvent-Everything where every developer everywhere has to reinvent everything poorly because the language is “concise” and “embeddable” and stuck in the 90s? Breaking changes between versions and interpre…

These points are well-known and many would agree if not for the tone of your comment and the missing context, which is:

I have been working on a research project to make writing VMs easier. . I chose Lua as the experiment target for my idea, mainly because

This is the most reasonable choice, because experimenting with a big one would drag all the complexity into the project but not the interesting parts. Which language would you suggest instead and why?

Re: Building the fastest Lua interpreter automatically

#37
post #33

I wonder why the target was 5.1 since 5.4 has been out for a while now?

Lua 5.2 introduced a new scoping rule (_ENV) that impacts the ability to implement efficient interpreters, which is why LuaJIT diverged from the main implementation. Insofar as Lua is notoriously the "fastest scripting language", Lua 5.1 is the "fastest Lua". I personally hope that the author eventually targets "LuaJIT flavored Lua", which incorporates some additional features from newer Lua without compromising the performance.

Edit: see replies

Re: Building the fastest Lua interpreter automatically

#39

> The problem with the “big switch-case” approach is that C/C++ compilers simply cannot handle such code well. Is this the case with Rust?

Yes, it will run into the same register allocation and unstructured control flow issues.
Post reply on HN