
LuaJIT 2.0.5 and 2.1.0-beta3 released - marksamman
http://luajit.org/
======
leafo
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](http://leafo.net/posts/itchio-and-coroutines.html)

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

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

[3] [https://itch.io/](https://itch.io/)

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

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

~~~
tiffanyh
Love Lapis.

Question, since Lapis just transcode Moonscript into Lua to be used with
OpenResty - why is Lapis so much slower than raw OpenResty/Lua?

[https://www.techempower.com/benchmarks/](https://www.techempower.com/benchmarks/)

~~~
killin_dan
Because the lua code moonsript emits is inherently slower.

~~~
leafo
Not really, the code mapping is very straightforward and generally has no
performance degradation. There are some language constructs that are
implemented in a way that can create anonymous functions in order to convert
statements into expressions. Future versions of MoonScript can do a better job
to eliminate those. If you're aware when they're generated you can avoid them
by writing as you might do in Lua. Realistically though, the performance
difference is negligible in comparison to all the other things that might
happen in your average web request.

------
fosk
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](http://luajit.org/ext_ffi.html)

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

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

~~~
placebo
> LuaJIT is such an amazing piece of software - apparently to such an extent
> that only Mike Pall fully understands some of its internals

Fully agree about the awesomeness of LuaJIT and incredible capabilities of
Mike Pall, but also the reason I've stopped considering using LuaJIT for
projects that should be "future proof". I think that depending on technology
which can only be maintained by one genius is too much of a risk.

------
sillysaurus3
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](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](https://gist.github.com/nddrylliog/8722197)

[http://hacksoflife.blogspot.fr/2012/12/integrating-luajit-
wi...](http://hacksoflife.blogspot.fr/2012/12/integrating-luajit-with-x-
plane-64-bit.html)

[https://en.blog.nic.cz/2015/08/12/embedding-luajit-
in-30-min...](https://en.blog.nic.cz/2015/08/12/embedding-luajit-
in-30-minutes-or-so/)

[http://luajit.org/install.html](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.)

~~~
daurnimator
> 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.

Why use LuaJIT over plain Lua here? I can't imagine that you need the extra
speed in a text editor. The ffi is available for normal lua too:
[https://github.com/facebook/luaffifb/](https://github.com/facebook/luaffifb/)

~~~
camperman
Because it's so easy. From the manual:

So here's something to pop up a message box on Windows:

    
    
        local ffi = require("ffi")
    
        ffi.cdef[[
    
            int MessageBoxA(void *w, const char *txt, const char *cap, int type);
    
        ]]
    
        ffi.C.MessageBoxA(nil, "Hello world!", "Test", 0)
    
    

Bing! Again, that was far too easy, no?

Compare this with the effort required to bind that function using the classic
Lua/C API: create an extra C file, add a C function that retrieves and checks
the argument types passed from Lua and calls the actual C function, add a list
of module functions and their names, add a luaopen_* function and register all
module functions, compile and link it into a shared library (DLL), move it to
the proper path, add Lua code that loads the module aaaand ... finally call
the binding function. Phew!

~~~
sillysaurus3
In fairness, luaffifb seems to give the same feature.

I think the main argument against Lua + luaffifb is that it might require an
external dependency: luarocks. Whereas if someone were to theoretically
provide Lua integration with emacs, it might be a good idea to offer the ffi
library as a baseline feature.

This is a weak argument, because it should be possible to embed luaffifb plus
Lua inside of a linked library, with no need to depend on luarocks.

It's probably best to explore both options.

~~~
shalabhc
Well, LuaJIT will also JIT compile Lua code operating on C structures - so
speed could be another big argument.

------
bakery2k
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](http://luajit.org/changes.html)

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

~~~
jshmrsn
Not only does LuaJIT have platform-specific assembly in its source, but a big
part of its advantage over PUC Lua is of course that it's compiling down to
machine language on the fly. And that process is also platform specific. I
have definitely seen bug fixes along the lines of "fix X for Y platform's JIT
output."

I have also seen non-jit-related bugs impact us in production.

BUT, LuaJIT _really_ is FASTER. Even when JIT cannot be used (e.g. on iOS), it
can still be several times faster than PUC Lua.

And that speed is a real killer feature for us. Otherwise, we'd just use
JavaScript.

~~~
rlp
Do you find LuaJIT much faster than a JavaScript engine like V8? That used to
be true, but I was under the impression that V8 had basically caught up
(unless you need to make a lot of FFI calls, since LuaJIT is heavily optimized
for that).

~~~
jshmrsn
I may be behind the times, but last I checked there was no way to use JITed
JavaScript in iOS apps. Or maybe you could put JS in a hidden webview, but
bridging to native was extra slow with this approach?

While LuaJIT can't be JITed either on iOS, I think the general consensus is
that non-jit Lua is faster than non-jit JS.

I do a lot of bridging Lua to native, and that's another area where Lua is
often considered more efficient.

Again, these thoughts may be out of date.

------
vvanders
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](http://luajit.org/performance_x86.html)

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

~~~
TillE
The most impressive part of LuaJIT is that its non-JIT'd interpreter is
_several times_ faster than Lua in benchmarks. Great for platforms like iOS
which don't allow code modification at runtime.

------
doomrobo
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](https://github.com/LuaJIT/LuaJIT/commits/master)

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

~~~
corsix
The commit author doesn't tell the whole story: the long description on most
of the recent commits mention somebody else.

------
shalabhc
For an editor built from the ground up using LuaJIT see
[https://howl.io](https://howl.io)

[/plug]

~~~
omaranto
The documentation could use a section explaining what Howl has to offer over
other text editors than are extensible using Lua, such as Textadept
([https://foicica.com/textadept/](https://foicica.com/textadept/)).

~~~
shalabhc
Good point. It's hard to highlight certain differences because it's a very
different editor. In general I think Howl offers a better API and a more
keyboard centric UI compared to Textadept. Most commands are operated via the
command line which offers auto-complete (vs operating via the menu bar, with
custom dialog boxes for each command). Howl also doesn't use Scintilla
(Textadept does) and is not subject to Scintilla's limits.

------
diegobernardes
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.

~~~
spc476
Batteries are not included in Lua. To do most anything interesting requires
third party libraries (like directory manipulations, network, etc).

~~~
Pxtl
Not just that, but Lua is very conservative about adding new language features
so a lot of quality of life things are missing - no ternary operator, verbose
lambda syntax, the incoherent mixing of arrays and dictionaries, bad default
scoping, stuff like that.

~~~
spc476
If you are willing to fork Lua (and it's been done---one example is Ravi,
which brings static typing) you can fix the verbose lambda syntax
([http://lua-users.org/lists/lua-l/2017-04/msg00387.html](http://lua-
users.org/lists/lua-l/2017-04/msg00387.html)) and add ternary operators (which
I haven't missed). I haven't found the mixing of arrays and dictionaries that
bad in practice (and I do a lot of Lua programming at work) and the default
scoping ... yeah, I can see that (I've learned to deal).

~~~
stevekemp
I had a fork a long time ago solely to allow the use of "?" in function-names.
Writing:

    
    
        function alive?
           ... blah
        end
    

Is so much more natural, after being exposed to ruby. But maintaining forks is
hard, so I've slowly gotten use to the standard.

It's a shame that the development is so conservative, and closed, but despite
that it is a great language to play with.

~~~
jpfr

        A function that tests for something involving its arguments
        is called a predicate and usually ends in p or -p.

[http://www.cliki.net/Naming+conventions](http://www.cliki.net/Naming+conventions)

------
rweichler
Build system in pure Lua:
[https://github.com/rweichler/aite](https://github.com/rweichler/aite)

3DS port:
[https://github.com/rweichler/luajit-3DS](https://github.com/rweichler/luajit-3DS)

iOS runtime inspector:
[https://github.com/rweichler/lucy](https://github.com/rweichler/lucy)

Cydia alternative:
[https://github.com/rweichler/jjjj](https://github.com/rweichler/jjjj)

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

------
i_feel_great
Don't forget the Not Yet Implemented features:
[http://wiki.luajit.org/NYI](http://wiki.luajit.org/NYI)

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

~~~
haberman
Those are just features that aren't _JIT compiled_. They are still
implemented, in the sense that LuaJIT fully supports them in the interpreter,
so you can use them in LuaJIT programs.

I'm guessing that pairs() is not JIT-compiled because iterating over a hash
table involves logic that is significantly more complicated than iterating
over an array (like ipairs()).

------
rkeene2
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

:-(

