Re: J2ME Implementation of Lua?

["Fabio Mascarenhas" <mascarenhas@...>]

On Tue, Apr 8, 2008 at 9:01 PM, David Given <dg@cowlark.com> wrote:
> Jeremy Irish wrote:
>  For example, I just found this:
>
>  http://www.lua.inf.puc-rio.br/luanet/lua2il_jucs.pdf
>
>  It's a paper on bytecode translation of Lua onto CLR. If CLR can do it,
>  I don't see any reason why the JVM can't; the two are architecturally
>  very similar.
>
>  Of particular interest is the table on page 12 showing the relative
>  speeds of the different approaches; translated Lua turned out to be
>  about the same speed as interpreted Lua. (And about half the speed of
>  interpreted Python, slightly faster than translated Python, and about an
>  order of magnitude faster than interpreted Python where the interpreter
>  itself was running on CLR... take note, if you want to write a Lua
>  interpreter running on JVM.)

I am the author of the paper. :-) Notice that the CLR (and the desktop
JVMs) have good JIT compilers, and this is how one can get good
results by bytecode translation (or straigth compilation). J2ME is
interpreted AFAIK so there will be a big speed hit. I don't know
enough about CLDC hotspot to comment... I recommend translating some
microbenchmarks by hand and testing them against interpretation with
Kahlua to see if the gains are worth the trouble.

One big downside of compilation or translation is that you lose
lightweight coroutines, and have to implement them using Java threads
and synchronization; but here I the opposite will happen wrt desktop
and embeddd JVMs, with desktop JVMs faring worse than embedded ones,
as the former will be using system threads and the latter will be
using "green" threads.

Another downside is code size, it's several times bigger than the
corresponding Lua bytecode because of all the extra checks.

>  *rummage*
>
>  Aha, the CLR bytecode translator's still being developed:
>
>  http://www.lua.inf.puc-rio.br/luaclr
>
>  I particularly like the phrase 'Benchmarks show the compiler to already
>  outperform the Lua interpreter for common operations...'

It's a source-to-CIL compiler, now, and faster than Lua on the
Richards benchmark, and way faster on some of the sillier shootout
benchmarks. Again, this is highly dependent on the JIT and GC of the
target platform. I will try to validate the results with the Hotspot
JVM, but I expect similar results.

--
Fabio Mascarenhas