Re: [ANN] LuaJIT-2.0.0-beta1

[Mike Pall <mikelu-0911@...>]

David Given wrote:
> I assume what you're using here are hand-translated versions of the
> SciMark benchmarks to each of the various languages? Is it:
> 
> http://luajit.org/download/scimark.lua
> 
> ...? What about the C version? I'd be interested to run it through Clue
> and see what happens.

http://math.nist.gov/scimark2/download.html

> Incidentally, I have tried to compare LuaJIT 2 with V8, but V8 doesn't
> seem to want to build easily these days. Last time I tried it I recall
> that it wasn't particularly fast compared to LuaJIT 1 anyway!

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=luajit&lang2=v8&box=1

Looks like V8 is only faster on the only recursive and allocation-
heavy benchmark in there. And it's much slower on all others.
Even LJ1 was often faster than V8.

Also check the ranking here:
  http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all&box=1

 1.00  C++
 1.02  C
 1.62  Java steady state
 1.86  Java
 2.11  Fortran
 2.32  ==> LuaJIT <==
 2.56  C# Mono
 ....
 9.77  JavaScript V8    
 ....
30.18  Ruby JRuby
34.22  JavaScript TraceMonkey
43.62  Ruby
44.45  Python
66.51  Perl

Ok, kicking Fortran will be easy. Next victim: Java.

> Anyway, it's very good to see this out, and it's impressively fast. It'd
> be very interesting to try doing traditionally high-CPU tasks with
> LuaJIT 2 and to see how well it works;

I need to add auto-vectorization for that. Other than that, it's
already a killer: someone just sent me a private mail where it
outperformed Java on heavily numerical code (real use case, not a
synthetic benchmark).

> I work in the mobile phone
> industry and it is *frightening* how shoddy the code tends to be. It'd
> be really nice to move away from traditional languages like C and C++
> and towards scripting languages like Lua.
> 
> Now I just have to wait for an ARM version...

Well, waiting is not a good tactic.

Collect requirements (desired number type, target architectures,
VFP or not etc.), collect funding, gather people who'd like to
work on it. In short: let me not drown in administrative stuff.
I'm more efficient at designing/coding.

[Sorry for the rant, please don't take it personally.]

--Mike