Re: Ravi performance update

[Coda Highland <chighland@...>]

On Wed, Jul 15, 2015 at 6:28 PM, Paige DePol <lual@serfnet.org> wrote:
> I do not know much about LuaJIT, is it a totally standalone compiler
> for lua code not based on any other compiler system?

Yes, it's completely hand-constructed. Additionally, it's explicitly a
JIT ("just-in-time") compiler, with no AOT ("ahead-of-time")
functionality.

> Hmm, I guess I am left wondering what magic LuaJIT is doing to achieve
> such dramatic compilation speeds compared to LLVM or GCC?

Lua is a VERY small language. Specializing for the specific set of
functionality that Lua needs allows the compiler to be made more
compact and efficient than a more general-purpose compiler
architecture.

Additionally, LuaJIT is ONLY a JIT compiler. Compilation speed is
therefore VERY important, and as such tradeoffs are made -- LuaJIT
only applies optimization transformations when they can be done
quickly, even if the resulting algorithm could theoretically be made
to run faster by a more intensive optimization process. LLVM and GCC
are both intended for AOT use with JIT being something of an
afterthought, so they focus on producing the fastest output they can
even if it takes longer to generate it.

It also aborts compilation if it expects it would take too long, or if
it hits code that it knows it can't optimize or trace, falling back to
its (also hand-constructed and fine-tuned) interpreter. If this causes
a performance hit visible to the developer, it's the developer's job
to make the changes to allow LuaJIT to compile the code successfully.
(It provides tools to see what's going on so you can do so.) So part
of being a LuaJIT user is helping the compiler do its best.

Another benefit: LuaJIT is a trace compiler, so it only compiles code
that's actually used -- and it does so at a finer granularity than
just whole functions at once, and it can make decisions based on the
values of variables. This is a big deal. It also won't waste time on
code that's only ever executed once.

The above points together require an additional point: LuaJIT does
LOTS of tiny compilations. If a code path gets too long, it breaks it
up. If a code path is hit with parameters that invalidate earlier
optimization assumptions, it recompiles it with the assumptions
broadened.

There's been a lot of talk (not just in the Lua/LuaJIT communities,
but in CS in general -- Java and C# both use JIT compilers in their
VMs, for example) about the benefits of tracing JIT compilation; in
theory, a tracing JIT compiler could potentially produce faster code
than AOT compilation in certain circumstances, because it can reason
about the code with real-world data instead of abstract static
analysis.

/s/ Adam