lua-users home
lua-l archive

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


Hi,

Vyacheslav Egorov wrote:
> Mike Pall wrote:
>> Most library functions (including pcall and yield) aren't C functions 
>> anymore.
>>   
> Have you adopted some kind of Jikes RVM approach (Lua VM written in Lua) or 
> something else?

Well, it doesn't go that far. It's currently a mix of Lua, C and
assembler. I'm trying to reduce the amount of C code, but won't
be able to get rid of all of it easily. The Lua VM is designed as
an extension to C, and I'm not going to drop this important part.

Self-hosting has two sides to it: one academic and one pragmatic.
Since LuaJIT is not a research project, I'm clearly aiming for
the pragmatic aspects. I.e. only as much self-hosting as it makes
sense and probably not all of it in the first cut either.

Library functions written in C are troublesome because they are
opaque to a Lua compiler. Without explicit knowledge about their
inner workings it has to assume the worst, i.e. arbitrary
side-effects. This severely limits most optimization
opportunities.

E.g. string.sub() implemented in C needs 8 branches, 9 calls and
the string interning (1-2 branches per sub-string byte if already
interned). Most of this overhead can be optimized away with type
inference, interval analysis, constant propagation and escape
analysis. But only if the compiler can completely analyze the
function in its calling context.

This is easy if there's an analyzable shadow copy of it written
in Lua. The primary function, written in C, assembler or
pre-compiled Lua, provides adequate performance for the fallback
case (called by the interpreter or not inlined).

OTOH it probably doesn't pay off to rewrite the garbage collector
in pure Lua. It's very unlikely that one can substantially exceed
the quality of the code generated by GCC. And even if one can
match the code quality, it doesn't provide any advantages to
(say) inline the whole GC code at every call site. Some time
critical parts like write barriers have already been rewritten in
hand-tuned assembler. And barrier elimination is not that
difficult either (even LuaJIT 1.x has a limited form of it).

Bye,
     Mike