lua-users home
lua-l archive

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


Jeremy Irish wrote:
> We want it to run *on* Java. As noted by others we don't want to have to worry about whether our C based engine can port to any particular device. In some cases (and platforms) we only have access to our own little Java sandbox.

Well, as someone else noted, there's Kahlua, but I've never used it.

If you don't need the ability to *compile* Lua code on the device, you
may want to look at bytecode translation. This may involve less work
than a full port, as you're making use of the existing compiler, as well
as getting you a much faster result.

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.)

*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...'

-- 
┌─── dg@cowlark.com ───── http://www.cowlark.com ─────
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup

Attachment: signature.asc
Description: OpenPGP digital signature