lua-users home
lua-l archive

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


2009/10/31 Mike Pall <mikelu-0910@mike.de>:
> It's almost midnight on Halloween here. This is the perfect time
> to release long-awaited, almost mythical open source software ... ;-)
>
> Yes, here it is: the first public release of LuaJIT 2.0!
>
> Here is a link to the home page:
>  http://luajit.org/luajit.html
>
> And a direct link to the download page:
>  http://luajit.org/download.html
>
> What is LuaJIT?
> ---------------
>
> LuaJIT is a Just-In-Time (JIT) Compiler for Lua. It's fully
> compatible with standard Lua 5.1 and can significantly boost the
> performance of your Lua programs.
>
> LuaJIT is open source software, released under the MIT/X license.
>
> LuaJIT builds out-of-the-box on all popular x86 operating systems
> (Linux, Windows, OSX etc.). It runs fine as a 32 bit application
> under x64-based systems, too.
>
> This is a BETA TEST release -- the current status and the list of
> known issues are shown here: http://luajit.org/status.html
> Please report any problems you may find with this release. Thank you!
>
> What's new in LuaJIT 2.0
> ------------------------
>
> The VM of LuaJIT 2.0 has been rewritten from the ground up and is
> relentlessly optimized for performance. It combines a high-speed
> interpreter, written in assembler, with a state-of-the-art JIT compiler.
>
> An innovative trace compiler is integrated with advanced, SSA-based
> optimizations and a highly tuned code generation backend. This allows a
> substantial reduction of the overhead associated with dynamic language
> features. It's destined to break into the performance range
> traditionally reserved for offline, static language compilers.
>
> Performance on numerical code is already quite competitive (see below).
> Support for other areas (e.g. string functions) is still a bit weak.
> Although the VM supports all Lua language features and standard library
> functions, the JIT compiler is not complete (yet) and falls back to the
> interpreter in some cases. All of this works transparently, so unless
> you use -jv, you'll probably never notice. The interpreter is quite
> fast, too (near the performance of the LuaJIT 1.x JIT compiler).
>
> Preliminary benchmark numbers are shown below -- performance will
> likely improve during the beta test phase. These numbers are mainly
> intended to give you an idea about the typical speedups you can expect,
> depending on the type of application. Your mileage may vary.
>
> Ok, so thanks to everyone for their patience! A big thank you goes to
> the alpha testers. And now, please have fun with it -- Happy Halloween!
>
> --Mike
>

I run my Lua test suite which is available with lua-TestMore
(testmore.luaforge.net).
See the full report at
http://smolder.plusthree.com/app/public_projects/report_details/29566
(currently, 1315 tests in 3 seconds).

I found the 2 same issues than with LuaJIT 1.1.5
1) numeric for with step = 0 causes infinite loop
    $ luajit -e 'for i = 5, 7, 0 do end'

2) losing arguments with metamethod __call
    m = {}
    setmetatable(m, {
        __call = function (obj, ...)
                     print('m.__call ' .. tostring(obj) .. ', ' ..
table.concat(arg, ', '))
                 end
    })
    m()
    m(1, 2) --> arguments are lost

and some new minor issues or delta :
1) getfenv(-3) gives a more general message :
    bad argument #1 to 'getfenv' (invalid level)
instead of
    bad argument #1 to 'getfenv' (level must be non-negative)
same issue with setfenv().

2) tostring of C function
    $ luajit -e 'print(tostring(print))'
    function: fast#29
when lua gives :
    function: 0x9a5d020

3) xpcall without error handler
    $ luajit -e 'print(xpcall(assert, nil))'
    luajit: (command line):1: bad argument #2 to 'xpcall' (function
expected, got nil)
instead of :
    false	error in error handling

4) table.maxn
    $ luajit -e 't = {3,4}; print(table.maxn(t))'
    1
instead of :
    2

5) deprecated table.setn
    $ luajit -e 'table.setn({},7)'
    luajit: (command line):1: attempt to call field 'setn' (a nil value)
instead of :
    lua: (command line):1: 'setn' is obsolete

6) math.random with extra arguments
    $ luajit -e 'print(math.random(1, 2, 3))'
    2
instead of :
    lua: (command line):1: wrong number of arguments


François Perrad

> Relative speedup over Lua 5.1.4 on standard Lua benchmarks
> (e.g. 11.9 means it's almost twelve times faster):
>
> md5           152.7  |  mandelbrot   13.4  |  nsieve        4.7  |
> array3d       101.5  |  pidigits     12.4  |  partialsums   4.1  |
> array          73.5  |  random       12.2  |  chameneos     3.8  |
> methcall       28.8  |  nsievebits   12.0  |  recursive     3.5  |
> nsievebits     28.0  |  nestedloop   11.9  |  knucleotide   3.4  |
> matrix         23.0  |  lists         9.3  |  binarytrees   2.7  |
> spectralnorm   21.4  |  cheapconcr    5.5  |  meteor        2.0  |
> fannkuch       20.9  |  cheapconcw    5.4  |  revcomp       1.8  |
> nbody          14.8  |  fasta         5.3  |  sumfile       1.5  |
>
> SciMark scores on a 3 GHz Core2 E8400 (single-thread, not vectorized),
> higher numbers are better:
>
> SciMark          composite  |
> small                score  |  FFT     SOR      MC    SPARSE    LU
> ----------------------------+---------------------------------------
> GCC 4.3.2            906.1  |  739.1   909.0   190.4  1057.0  1635.1
> JVM 1.6 Server       876.3  |  573.8  1185.5   297.7   579.2  1745.4
> JVM 1.6 Client       579.6  |  424.8   895.8   122.8   595.5   859.0
> ----------------------------+---------------------------------------
> LuaJIT 2.0.0-beta1   580.4  |  427.4  1025.0   223.7   303.4   922.5
> LuaJIT 1.1.5          96.7  |   72.0   166.1    37.1    91.8   116.5
> Lua 5.1.4             16.5  |   11.0    27.4     7.6    16.9    19.5
>
> Get the newest Lua SciMark here: http://luajit.org/download/scimark.lua
>
>
>