+Here are some performance measurements, based on a few benchmarks. +
+
+LuaJIT 2.0 is available with much improved performance!
+Please check the new
+» interactive performance comparison.
+
Interpreting the Results
++As is always the case with benchmarks, care must be taken to +interpret the results: +
++First, the standard Lua interpreter is already very fast. +It's commonly the fastest of it's class (interpreters) in the +» Great Computer Language Shootout. +Only true machine code compilers get a better overall score. +
++Any performance improvements due to LuaJIT can only be incremental. +You can't expect a speedup of 50x if the fastest compiled language +is only 5x faster than interpreted Lua in a particular benchmark. +LuaJIT can't do miracles. +
++Also please note that most of the benchmarks below are not +trivial micro-benchmarks, which are often cited with marvelous numbers. +Micro-benchmarks do not realistically model the performance gains you +can expect in your own programs. +
+
+It's easy to make up a few one-liners like:
+ local function f(...) end; for i=1,1e7 do f() end
+This is more than 30x faster with LuaJIT. But you won't find
+this in a real-world program.
+
Measurement Methods
++All measurements have been taken on a Pentium III 1.139 GHz +running Linux 2.6. Both Lua and LuaJIT have been compiled with +GCC 3.3.6 with -O3 -fomit-frame-pointer. +You'll definitely get different results on different machines or +with different C compiler options. * +
++The base for the comparison are the user CPU times as reported by +/usr/bin/time. The runtime of each benchmark is parametrized +and has been adjusted to minimize the variation between several runs. +The ratio between the times for LuaJIT and Lua gives the speedup. +Only this number is shown because it's less dependent on a specific system. +
++E.g. a speedup of 6.74 means the same benchmark runs almost 7 times +faster with luajit -O than with standard Lua (or with +-j off). Your mileage may vary. +
++* Yes, LuaJIT relies on quite a bit of the Lua core infrastructure +like table and string handling. All of this is written in C and +should be compiled with full optimization turned on, or performance +will suffer. +
+ +Comparing Lua to LuaJIT
++Here is a comparison using the current benchmark collection of the +» Great Computer Language Shootout (as of 3/2006): +
+ +| Benchmark | +Speedup | +
+
+ |
+
| mandelbrot | +6.74 | + |
+
| recursive | +6.64 | + |
+
| fannkuch | +5.37 | + |
+
| chameneos | +5.08 | + |
+
| nsievebits | +5.05 | + |
+
| pidigits | +4.94 | + |
+
| nbody | +4.63 | + |
+
| spectralnorm | +4.59 | + |
+
| cheapconcr | +4.46 | + |
+
| partialsums | +3.73 | + |
+
| fasta | +2.68 | + |
+
| cheapconcw | +2.52 | + |
+
| nsieve | +1.95 | + |
+
| revcomp | +1.92 | + |
+
| knucleotide | +1.59 | + |
+
| binarytrees | +1.52 | + |
+
| sumfile | +1.27 | + |
+
| regexdna | +1.01 | + |
+
+Note that many of these benchmarks have changed over time (both spec +and code). Benchmark results shown in previous versions of LuaJIT +are not directly comparable. The next section compares different +versions with the current set of benchmarks. +
+ +Comparing LuaJIT Versions
++This shows the improvements between the following versions: +
+-
+
- LuaJIT 1.0.x
+
- LuaJIT 1.1.x
+
| Benchmark | +Speedup | +
+
+ |
+
| fannkuch | +3.96 → 5.37 | + |
+
| chameneos | +2.25 → 5.08 | + |
+
| nsievebits | +2.90 → 5.05 | + |
+
| pidigits | +3.58 → 4.94 | + |
+
| nbody | +4.16 → 4.63 | + |
+
| cheapconcr | +1.46 → 4.46 | + |
+
| partialsums | +1.71 → 3.73 | + |
+
| fasta | +2.37 → 2.68 | + |
+
| cheapconcw | +1.27 → 2.52 | + |
+
| revcomp | +1.45 → 1.92 | + |
+
| knucleotide | +1.32 → 1.59 | + |
+
+All other benchmarks show only minor performance differences. +
+ +Summary
++These results should give you an idea about what speedup +you can expect depending on the nature of your Lua code: +
+-
+
- +LuaJIT is really good at (floating-point) math and loops +(mandelbrot, pidigits, spectralnorm, partialsums). + +
- +Function calls (recursive), vararg calls, table lookups (nbody), +table iteration and coroutine switching (chameneos, cheapconc) +are a lot faster than with plain Lua. + +
- +It's still pretty good for indexed table access (fannkuch, nsieve) +and string processing (fasta, revcomp, knucleotide). +But there is room for improvement in a future version. + +
- +If your application spends most of the time in C code +you won't see much of a difference (regexdna, sumfile). +Ok, so write more code in pure Lua. :-) + +
-
+The real speedup may be shadowed by other dominant factors in a benchmark:
+
-
+
- Common parts of the Lua core: e.g. memory allocation +and GC (binarytrees). +
- Language characteristics: e.g. lack of bit operations (nsievebits). +
- System characteristics: e.g. CPU cache size and memory speed (nsieve). +
+
+The best idea is of course to benchmark your own applications. +Please report any interesting results you may find. Thank you! +
++