from Hacker News

LuaJIT 2.0.5 and 2.1.0-beta3 released

by marksamman on 5/1/17, 8:33 PM with 67 comments

  • by leafo on 5/2/17, 12:03 AM

    LuaJIT powers OpenResty[1] which powers my web framework Lapis[2] which powers my company itch.io[3]! (wow that's a mouthful)

    Anyway, it's a stack I'm really happy to be using. Asynchronous IO without any code nesting. I wrote more about the benefits here: http://leafo.net/posts/itchio-and-coroutines.html

    [1] https://openresty.org/en/

    [2] http://leafo.net/lapis/

    [3] https://itch.io/

    I also made web server infrastructure for the Lua package manager LuaRocks in the same stack: https://luarocks.org Source is on github: https://github.com/luarocks/luarocks-site

    Lua (especially with LuaJIT) is a great choice for web development.

  • by fosk on 5/1/17, 11:58 PM

    LuaJIT is such an amazing piece of software - apparently to such an extent that only Mike Pall fully understands some of its internals. Besides being much faster than the official Lua VM, it offers extended features like the FFI library [1].

    Kong[2] uses it extensively, by leveraging the underlying OpenResty[3] framework.

    [1] http://luajit.org/ext_ffi.html

    [2] https://github.com/Mashape/kong

    [3] https://github.com/openresty/lua-nginx-module

  • by bakery2k on 5/2/17, 2:27 AM

    Looking at the LuaJIT changelog [1], it's interesting how many bugs need fixing in each version: 20 in 2.0.5 and 32 in 2.0.4.

    Compare this with PUC Lua [2], which seems to have very few bugs: only 4 in 5.3.3 and 3 in 5.3.2.

    LuaJIT and PUC Lua appear to be very similar superficially ("LuaJIT is Lua, but fast"). The relative bug counts reinforce the fact that in the details, the two implementations are very different - for example, LuaJIT uses a lot of assembly language while PUC Lua is pure C89.

    The advantages of LuaJIT over PUC Lua seem to be performance and its FFI. I thought PUC Lua's only advantage was portability, but perhaps PUC Lua is also a generally more "correct" implementation?

    [1] http://luajit.org/changes.html

    [2] https://www.lua.org/bugs.html

  • by vvanders on 5/1/17, 10:12 PM

    If you want to get an idea just how good LuaJIT is take a look at these benchmarks against the stock VM(which is already good) [1][2]

    We used to run Lua on a 300MHz MIPS processor and it was impressive in how well it worked on that constrained platform(only 8mb is system ram, of that Lua ran in a fixed 400kb block).

    [1] - http://luajit.org/performance_x86.html

    [2] - http://luajit.org/performance.html

  • by doomrobo on 5/1/17, 9:40 PM

    Didn't Mike Pall step down sometime last year? It looks like he's made a ton of commits [0] and also made the announcements on the mailing list [1]. Anyways, congrats on the new release!

    [0] https://github.com/LuaJIT/LuaJIT/commits/master

    [1] https://www.freelists.org/archive/luajit/05-2017

  • by shalabhc on 5/1/17, 11:44 PM

    For an editor built from the ground up using LuaJIT see https://howl.io

    [/plug]

  • by diegobernardes on 5/2/17, 12:44 AM

    Really can't understant why Lua isn't more used. It play the same role as Ruby, Python and JS and is very fast, at least, much more then Ruby and Python.

  • by rweichler on 5/2/17, 7:25 AM

    Build system in pure Lua: https://github.com/rweichler/aite

    3DS port: https://github.com/rweichler/luajit-3DS

    iOS runtime inspector: https://github.com/rweichler/lucy

    Cydia alternative: https://github.com/rweichler/jjjj

    And this is just stuff by me, some schlep. LuaJIT is so underrated it's kind of sad.

  • by i_feel_great on 5/2/17, 12:13 AM

    Don't forget the Not Yet Implemented features: http://wiki.luajit.org/NYI

    Edit: By the way, can someone explain why ipairs() is implemented, but not pairs()?

  • by rkeene2 on 5/2/17, 11:47 PM

    I'm still unable to use LuaJIT because the build system makes an incorrect and silly assumption that code compiled during the build by the build compiler had the same executable properties as the code compiled during the build by the host compiler, leading to the situation where: repeatable builds don't work, and you can't compile for Linux/x86_64 from Linux/x86 or Linux/arm.

    It is one of very few packages broken this way, along with basically only XFree86 4.8.0

    :-(

  • by sillysaurus3 on 5/1/17, 10:10 PM

    I hooked up LuaJIT to emacs for fun. Emacs recently released a new module system where you can build DLLs that are loaded dynamically: http://diobla.info/blog-archive/modules-tut.html

    Getting LuaJIT to work on 64-bit OS X required building a custom emacs with linker flags -pagezero_size 10000 -image_base 100000000. This is unfortunate since obviously users will not take the time to build an emacs with custom linker flags. But more generally, this is an issue any time you want to embed LuaJIT in an application plugin rather than the application itself.

    There's a bunch of scattered info about the issue:

    https://gist.github.com/nddrylliog/8722197

    http://hacksoflife.blogspot.fr/2012/12/integrating-luajit-wi...

    https://en.blog.nic.cz/2015/08/12/embedding-luajit-in-30-min...

    http://luajit.org/install.html

    I was hoping there might be a way of sidestepping the issue somehow. If anyone has any ideas, it would be appreciated. LuaJIT has some nice speed improvements compared to standard Lua, but more importantly it has a pretty amazing FFI library. The C declaration parser in particular is valuable.

    (Yes, I know it's pointless to hook LuaJIT to emacs. It's mostly a "just because" project.)