48

According to the computer language benchmark game, the LuaJIT implementation seems to beat every other JIT-ed dynamic language (V8, Tracemonkey, PLT Scheme, Erlang HIPE) by an order of magnitude.

I know that these benchmarks are not representative (as they say: "Which programming language implementations have the fastest benchmark programs?"), but this is still really impressive.

In practice, is it really the case? Someone have tested that Lua implementation?

Nicol Bolas
  • 378,677
  • 53
  • 635
  • 829
Gabriel Cuvillier
  • 3,403
  • 1
  • 25
  • 31
  • 2
    >> I know that these benchmarks are not representative << Do you? The reminder is that they don't claim to be representative of everything you might want to do. It's up to you to understand how those tiny programs are like (or not like) the programs you write. – igouy Apr 07 '10 at 16:32
  • 4
    @igouy: If he thought the benchmarks were representative, he wouldn't have asked this question. The question is asking for corroboration of these results. – Mud May 26 '12 at 01:43

4 Answers4

33

There's a good discussion at Lambda the Ultimate. LuaJIT is very good.

Many people have reported impressive speedups on lua-l (the lua mailing list). The speedups are most impressive for pure Lua code; the trace compiler is not as effective when there are lots of calls to C functions in loadable library modules.

Community
  • 1
  • 1
Doug Currie
  • 38,699
  • 1
  • 88
  • 113
  • 1
    As Justin Cormack notes in the comments to the answer below, it is *crucial* to remark that JITed calls to native C functions (rather than lua_CFunctions) are extremely fast (zero overhead) when using the LuaJIT ffi. That's a double win: you don't have to write bindings anymore, *and* you get on-the-metal performance. Using LJ to call into a C library can yield spooky-fast performance even when doing heavy work on the Lua side. – Josh Parnell Aug 22 '18 at 20:32
  • I am personally surprised at luajit's performance. We use it in the network space, and its performance is outstanding. I had used it in the past is a different manner, and its performance was 'ok'. Implementation architecture really is important with this framework. You can get C perf, with minimal effort. There are limitations, but we have worked around all of them now. Highly recommended. – David Lannan Oct 14 '20 at 12:01
15

In my case (a game prototype development), I observed no performance improvement at all. I use lua for embedding, so there are lots of calls to C++ library functions. Even though main loop is in a lua script and all of the important logic is implemented in lua, the overall performance was determined by rendering engines and physics engines implemented in C++. The original lua is already fast enough for such applications.

hippietrail
  • 13,703
  • 15
  • 87
  • 133
tbear
  • 550
  • 4
  • 6
  • I made a similar experience. Yes, luajit is much faster for pure lua, but it won't speed up your calls to C. I used luabind for wrapping(probably a bad idea), and I ended up spending more time in object wrapper calls than in my lua functions. – cib Sep 25 '11 at 00:32
  • 20
    If you use the LuaJIT ffi interface to call C functions they get natively inlined by the jit compiler, and this will be much faster. I have called Linux system calls at the same speed as C does. – Justin Cormack Oct 02 '11 at 16:05
  • For tbear and cib the problem is not the overhead of calling into C, but rather that all the time was being spent inside the C functions. Of course in that case Lua is not a part of the bottleneck and speeding it up will yield no improvement. – Eloff Mar 19 '13 at 14:53
  • 2
    Note that LuaJIT is configured not to do any JITing on iOS. This is because Apple doesn't approve iOS apps that can compile code. Are you developing on iOS? – chowey Apr 20 '13 at 20:09
  • @JustinCormack Sorry to ping you on something this old but this comment has me curious. Are you sure that's something LuaJIT can do? The [LuaJit homepage](http://luajit.org/ext_ffi_semantics.html) seems to say otherwise: "[...] neither the C compiler nor LuaJIT can inline or optimize across the language barrier [...]" – Praxeolitic Nov 18 '16 at 20:21
  • @Praxeolitic sorry, I meant the function call is inlined, not the actual function contents are inlined, so its the same speed as calling a C function, that probably wasnt clear. – Justin Cormack Dec 04 '16 at 14:11
6

I made an experiment with the lesson learned here: http://www.sampalib.org/luajit2.0_tunning.html Some data are not that valid anymore ( maxmcode=1024 is enough ), but luajit brings a robust improvement on a 600 lines of code pure Lua script (no C call to hit perfs...) that is not a large scale application nor an embedded use case but much more than the benchmarks.

Thierry Grellier
  • 61
  • 1
-2

The performance of JIT depends on two things: performance of original scripting language, and the performance of the compiler.

Compiler is a pretty mature technique and most JIT compiler have comparable performance. However, lua itself, i.e. lua-without-JIT, is probably one of the fastest scripting language.

lua is faster than Java-without-JIT. lua is faster than Javascript-without-JIT. lua is faster than most-scripting-languages-without-JIT.

so,

lua-JIT is faster than Java-with-JIT (the sun Java), lua-JIT is faster than V8 (Javascript-with-JIT), etc, ...

pansz
  • 160
  • 1
  • 5
  • 6
    Most JIT compilers don't have comparable performance. Lua for the most part lends itself well for interpreter and JIT performance, but this isn't the deciding factor that it's made to be. LuaJIT is not 'faster' than the Sun JVM, although it is comparable. Also LuaJIT's interpreter is completely different from PUC Lua's. – jsimmons Jun 17 '12 at 06:34