Re: J2ME Implementation of Lua?

["Gerardo Horvilleur" <mago@...>]

There are huge speed differences between J2ME implementations. I've
measured the times for some simple benchmarks in various phones and
I've seen ratios up to a 100 to 1 between different phones.
Sony Ericsson and Nokia phones have an excellent implementation of
Java. It is very fast (I'm sure they do have something similar to the
Hotspot compiler used in desktop and server JVM). On the other hand,
the Motorola and Samsung phones I've tested have a very poor
performance.

On Tue, Apr 8, 2008 at 9:47 PM, Fabio Mascarenhas <mascarenhas@acm.org> wrote:
> 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
>



-- 
Gerardo Horvilleur
mago@simplej.com
5813-0830