lua-users home
lua-l archive

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



On Jan 13, 2014, at 5:22 PM, Journeyer J. Joh <oosaprogrammer@gmail.com> wrote:

Hi David Olofson,

Thank you!
Then Lua VM would be similar to the ones in JVM or .net or Dalvic.

Thank you very much.
Journeyer


Yes and no.

Java was originally a pure VM. The compiler emitted a pseudo machine code (“bytecode”) that was then interpreted at run time by a VM; no native machine code was generated. The advantage of course is portability; just port the VM and all compiled code runs anywhere (no need to recompile). The disadvantage was poor performance, as the interpreter ran much slower than native compiled code (10x or worse). To overcome this, later Java VMs added a JIT layer that converted bytecode to native machine code (the so-called “hotspot” VM). This improved performance, as long as the faster execution time was able to offset the hotspot JIT overhead. However, the JIT was crippled by the fact that bytecode is a low-level representation of the original program, and performing low-level optimizations (such as register allocation) was nearly impossible to do well.

Unlike Java, the .Net model was designed as a JIT from day one. The various .Net compilers (C# etc) emit an intermediate pseudo machine code called MSIL, which is closer (in intent) to the internal intermediate representation used by native code compilers. Unlike Java bytecode, MSIL contains significantly more information about the source file, allowing the JIT stage to generate code that rivals native code compilers. This is also the approach used by LLVM (though in fact LLVM goes further in that it is able to constant-fold at run-time and thus collapse run-time invariant code).

Lua uses an approach similar to the original Java VM (and others that predate it all the way back to the P-System and others); the compiler emits Lua “bytecode” (in the generic sense, it’s nothing to do with Java bytecode) and the Lua VM directly interprets that bytecode — there is no JIT (unless you switch to the 3rd party LuaJIT compiler). Generally, however, (imho) the Lua bytecode is more efficient than the equivalent Java bytecode, resulting in a lower run-time performance penalty than the original Java.

So, Lua is nearest to the original Java, but better :)

—Tim