lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Fri, 21 Feb 2020 at 21:55, Dibyendu Majumdar <> wrote:
> Lua's inbuilt parser and code generator is a work of art, very compact
> and low overhead but extremely fast. It uses minimal memory and
> produces bytecodes as it parses the source code (single pass
> compiler). This is great for Lua and Ravi given the use cases of these
> languages, but makes the parser and code generator quite hard to
> understand, play with, or reuse in tools such as IDEs. It also makes
> it harder to perform any advanced type checking or performance
> optimizations.
> I am pleased to announce a new project to create a Lua/Ravi parser and
> code generator that is not a replacement for the default one in
> Lua/Ravi but can be used for more specialised code generation, as well
> as as a means of understanding how the parser and code generator
> works.

The new approach has enabled AOT compilation.

For examples see:

So what are the benefits of this new project?

The same code can be compiled using LLVM in the original Ravi JIT
implementation. The original JIT backend worked on bytecodes and
translated those to LLVM IR.

The new approach works off the Lua/Ravi source code and uses a new
intermediate instruction set (IR or bytecode). This is then translated
to C code and then compiled either using the MIR JIT backend or AOT
using gcc or clang.

The main benefit of the new approach is better code generation, that
helps the MIR JIT backend achieve performance closer to the LLVM
backend. For instance here are some benchmarks:

A) Matrix multiplication:

Interpreted: 8.65 secs
LLVM using Ravi bytecodes: 0.93 secs
MIR JIT using Ravi bytecodes: 2.59 secs
MIR JIT using new approach: 0.99 secs
AOT (gcc) using new approach: 0.91 secs

B) Sieve

Interpreted: 19.26 secs
LLVM using Ravi bytecodes: 5.77 secs
MIR JIT using Ravi bytecodes: 7.87 secs
MIR JIT using new approach: 5.22 secs
AOT (gcc) using new approach: 3.26 secs

In effect the new approach will allow me to deprecate LLVM and use MIR
JIT as the backend - the latter being much smaller.

The project is in early days and there is much scope for optimization
in the new compiler. So it can only get better as time goes.