Re: Re: Lua is faster than Java?

[Jamie Webb <j@...>]

On Tue, Jul 26, 2005 at 10:36:18AM +0800, ouli wrote:
> on 2005-07-25, David Olofson write:
> >On Monday 25 July 2005 04.40, ouli wrote:
> >> 
> >>     I've read things like "Lua is faster than Java ".
> >
> >I believe it is, if you compare under fair circumstances; ie
> >similar implementations or similar hardware. The Lua VM is more
> >effective by design.
> 
>     I believe it,too, since I use lua in our project on 2003. But I
>     had a little beaten yesterday, when somebody show me the
>     Benchmarks on shootout.alioth.debian.org . I just can not
>     believe Java is 3X faster then lua! Then we search other
>     Benchmarks. Oh, I am depressed, the result is the same: Java's
>     ranks is higher than lua's. I be certain of that there is
>     something wrong with the Benchmarks. But I can not persuade the
>     guy who show me the Benchmarks. Of course, he is a java fan.  

Your benchmarks will not be comparing like for like. But then Java and
Lua are not very similar languages. You have to choose which one is
right for each project.

When run on a JIT VM (e.g. Sun's), and given the opportunity to
compile (e.g. in repetetive benchmarks; Sun's VM tends to interpret
code the first couple of times it is seen), Java will be easily 3x
faster than Lua for computation-bound tasks. Sometimes much more.
Potentially Java can approach C performance in these situations (in
fact Sun can show you benchmarks of very specific situations in which
Hotspot can actually outperform C, but you won't come accross that in
the wild; 70% of C performance appears more realistic for numeric
stuff).

Java performance is often percieved poorly because the huge VM takes a
long time to start, and due to the bad design of libraries such as
Swing.

Until Mike's work is released, Lua is interpretive only, and can only
fairly be compared to interpretive JVMs, such as GIJ. It appears to
outperform these handily.

So, situations where Java will typically be faster than Lua:

- Longer running processes on well-supported architectures.

And where Lua will typically be faster than Java:

- On architectures where no JIT JVM is available.
- For very short-running processes.

Some other cases where Lua's small footprint may give it the edge:

- For memory- or IO-bound programs.
- For programs where very little code is repeated enough to warrant
  compiling, e.g. because all the inner loops are coded in C.

...and of course these last two categories describe many games.

-- Jamie Webb