doc/status.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
   2 <html>
   3 <head>
   4 <title>Status &amp; Roadmap</title>
   5 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   6 <meta name="Author" content="Mike Pall">
   7 <meta name="Copyright" content="Copyright (C) 2005-2011, Mike Pall">
   8 <meta name="Language" content="en">
   9 <link rel="stylesheet" type="text/css" href="bluequad.css" media="screen">
  10 <link rel="stylesheet" type="text/css" href="bluequad-print.css" media="print">
  11 <style type="text/css">
  12 ul li { padding-bottom: 0.3em; }
  13 </style>
  14 </head>
  15 <body>
  16 <div id="site">
  17 <a href="http://luajit.org"><span>Lua<span id="logo">JIT</span></span></a>
  18 </div>
  19 <div id="head">
  20 <h1>Status &amp; Roadmap</h1>
  21 </div>
  22 <div id="nav">
  23 <ul><li>
  24 <a href="luajit.html">LuaJIT</a>
  25 <ul><li>
  26 <a href="install.html">Installation</a>
  27 </li><li>
  28 <a href="running.html">Running</a>
  29 </li></ul>
  30 </li><li>
  31 <a href="extensions.html">Extensions</a>
  32 <ul><li>
  33 <a href="ext_ffi.html">FFI Library</a>
  34 <ul><li>
  35 <a href="ext_ffi_tutorial.html">FFI Tutorial</a>
  36 </li><li>
  37 <a href="ext_ffi_api.html">ffi.* API</a>
  38 </li><li>
  39 <a href="ext_ffi_int64.html">64 bit Integers</a>
  40 </li><li>
  41 <a href="ext_ffi_semantics.html">FFI Semantics</a>
  42 </li></ul>
  43 </li><li>
  44 <a href="ext_jit.html">jit.* Library</a>
  45 </li><li>
  46 <a href="ext_c_api.html">Lua/C API</a>
  47 </li></ul>
  48 </li><li>
  49 <a class="current" href="status.html">Status</a>
  50 <ul><li>
  51 <a href="changes.html">Changes</a>
  52 </li></ul>
  53 </li><li>
  54 <a href="faq.html">FAQ</a>
  55 </li><li>
  56 <a href="http://luajit.org/performance.html">Performance <span class="ext">&raquo;</span></a>
  57 </li><li>
  58 <a href="http://luajit.org/download.html">Download <span class="ext">&raquo;</span></a>
  59 </li></ul>
  60 </div>
  61 <div id="main">
  62 <p>
  63 The <span style="color: #0000c0;">LuaJIT 1.x</span> series represents
  64 the current <span style="color: #0000c0;">stable branch</span>.
  65 Only a single bug has been discovered in the last two years. So, if
  66 you need a rock-solid VM, you are encouraged to fetch the latest
  67 release of LuaJIT 1.x from the <a href="http://luajit.org/download.html"><span class="ext">&raquo;</span>&nbsp;Download</a>
  68 page.
  69 </p>
  70 <p>
  71 <span style="color: #c00000;">LuaJIT 2.0</span> is the currently active
  72 <span style="color: #c00000;">development branch</span>.
  73 It has <b>Beta Test</b> status and is still undergoing
  74 substantial changes.
  75 It has <a href="http://luajit.org/performance.html"><span class="ext">&raquo;</span>&nbsp;much better performance</a> than LuaJIT 1.x.
  76 It's maturing quickly, so you should definitely
  77 start to evaluate it for new projects right now.
  78 </p>
  79
  80 <h2>Current Status</h2>
  81 <p>
  82 This is a list of the things you should know about the LuaJIT 2.0 beta test:
  83 </p>
  84 <ul>
  85 <li>
  86 Obviously there will be many <b>bugs</b> in a VM which has been
  87 rewritten from the ground up. Please report your findings together with
  88 the circumstances needed to reproduce the bug. If possible, reduce the
  89 problem down to a simple test case.<br>
  90 There is no formal bug tracker at the moment. The best place for
  91 discussion is the
  92 <a href="http://www.lua.org/lua-l.html"><span class="ext">&raquo;</span>&nbsp;Lua mailing list</a>. Of course
  93 you may also send your bug reports <a href="contact.html">directly to me</a>,
  94 especially when they contain lengthy debug output or if you require
  95 confidentiality.
  96 </li>
  97 <li>
  98 The x86 JIT compiler only generates code for CPUs with support for
  99 <b>SSE2</b> instructions. I.e. you need at least a P4, Core 2/i3/i5/i7,
 100 Atom or K8/K10 to get the full benefit.<br>
 101 If you run LuaJIT on older CPUs without SSE2 support, the JIT compiler
 102 is disabled and the VM falls back to the LuaJIT interpreter. This is faster
 103 than the Lua interpreter, but not nearly as fast as the JIT compiler of course.
 104 Run the command line executable without arguments to show the current status
 105 (<tt>JIT: ON</tt> or <tt>JIT: OFF</tt>).
 106 </li>
 107 <li>
 108 The VM is complete in the sense that it <b>should</b> run all Lua code
 109 just fine. It's considered a serious bug if the VM crashes or produces
 110 unexpected results &mdash; please report this. There are only very few
 111 known incompatibilities with standard Lua:
 112 <ul>
 113 <li>
 114 The Lua <b>debug API</b> is missing a couple of features (return
 115 hooks for non-Lua functions) and shows slightly different behavior
 116 (no per-coroutine hooks, no tail call counting).
 117 </li>
 118 <li>
 119 <b>Bytecode</b> currently cannot be loaded or dumped. Note that
 120 the bytecode format differs from Lua&nbsp;5.1 &mdash; loading foreign
 121 bytecode is not supported at all.
 122 </li>
 123 <li>
 124 Some of the <b>configuration options</b> of Lua&nbsp;5.1 are not supported:
 125 <ul>
 126 <li>The <b>number type</b> cannot be changed (it's always a <tt>double</tt>).</li>
 127 <li>The stand-alone executable cannot be linked with <b>readline</b>
 128 to enable line editing. It's planned to add support for loading it
 129 on-demand.</li>
 130 </ul>
 131 </li>
 132 <li>
 133 Most other issues you're likely to find (e.g. with the existing test
 134 suites) are differences in the <b>implementation-defined</b> behavior.
 135 These either have a good reason (like early tail call resolving which
 136 may cause differences in error reporting), are arbitrary design choices
 137 or are due to quirks in the VM. The latter cases may get fixed if a
 138 demonstrable need is shown.
 139 </li>
 140 </ul>
 141 </li>
 142 <li>
 143 The <b>JIT compiler</b> falls back to the
 144 interpreter in some cases. All of this works transparently, so unless
 145 you use <tt>-jv</tt>, you'll probably never notice (the interpreter is
 146 <a href="http://luajit.org/performance.html"><span class="ext">&raquo;</span>&nbsp;quite fast</a>, too). Here are the known issues:
 147 <ul>
 148 <li>
 149 Most known issues cause a <b>NYI</b> (not yet implemented) trace abort
 150 message. E.g. for calls to some internal library
 151 functions. Reporting these is only mildly useful, except if you have good
 152 example code that shows the problem. Obviously, reports accompanied with
 153 a patch to fix the issue are more than welcome. But please check back
 154 with me, before writing major improvements, to avoid duplication of
 155 effort.
 156 </li>
 157 <li>
 158 The trace compiler currently doesn't back off specialization for
 159 function call dispatch. It should really fall back to specializing on
 160 the prototype, not the closure identity. This can lead to the so-called
 161 "trace explosion" problem with <b>closure-heavy programming</b>. The
 162 trace linking heuristics prevent this, but in the worst case this
 163 means the code always falls back to the interpreter.
 164 </li>
 165 <li>
 166 <b>Trace management</b> needs more tuning: less drastic countermeasures
 167 against trace explosion and better heuristics in general.
 168 </li>
 169 <li>
 170 Some checks are missing in the JIT-compiled code for obscure situations
 171 with <b>open upvalues aliasing</b> one of the SSA slots later on (or
 172 vice versa). Bonus points, if you can find a real world test case for
 173 this.
 174 </li>
 175 <li>
 176 Currently some <b>out-of-memory</b> errors from <b>on-trace code</b> are not
 177 handled correctly. The error may fall through an on-trace
 178 <tt>pcall</tt> (x86) or it may be passed on to the function set with
 179 <tt>lua_atpanic</tt> (x64).
 180 </li>
 181 </ul>
 182 </li>
 183 </ul>
 184
 185 <h2>Roadmap</h2>
 186 <p>
 187 Rather than stating exact release dates (I'm well known for making
 188 spectacularly wrong guesses), this roadmap lists the general project
 189 plan, sorted by priority, as well as ideas for the future:
 190 </p>
 191 <ul>
 192 <li>
 193 The main goal right now is to stabilize LuaJIT 2.0 and get it out of
 194 beta test. <b>Correctness</b> has priority over completeness. This
 195 implies the first stable release will certainly NOT compile every
 196 library function call and will fall back to the interpreter from time
 197 to time. This is perfectly ok, since it still executes all Lua code,
 198 just not at the highest possible speed.
 199 </li>
 200 <li>
 201 The next step is to get it to compile more library functions and handle
 202 more cases where the compiler currently bails out. This doesn't mean it
 203 will compile every corner case. It's much more important that it
 204 performs well in a majority of use cases. Every compiler has to make
 205 these trade-offs &mdash; <b>completeness</b> just cannot be the
 206 overriding goal for a low-footprint, low-overhead JIT compiler.
 207 </li>
 208 <li>
 209 More <b>optimizations</b> will be added in parallel to the last step on
 210 an as-needed basis. Sinking of stores
 211 to aggregates and sinking of allocations are high on the list.
 212 More complex optimizations with less pay-off, such as value-range-propagation
 213 (VRP) will have to wait.
 214 </li>
 215 <li>
 216 LuaJIT 2.0 has been designed with <b>portability</b> in mind.
 217 Nonetheless, it compiles to native code and needs to be adapted to each
 218 architecture. The two major work items are porting the the fast interpreter,
 219 which is written in assembler, and porting the compiler backend.
 220 Most other portability issues like endianess or 32 vs. 64&nbsp;bit CPUs
 221 have already been taken care of.<br>
 222 Several ports are already available, thanks to the
 223 <a href="http://luajit.org/sponsors.html"><span class="ext">&raquo;</span>&nbsp;LuaJIT sponsorship program</a>.
 224 More ports will follow in the future &mdash; companies which are
 225 interested in sponsoring a port to a particular architecture, please
 226 use the given contact address.
 227 </li>
 228 <li>
 229 <b>Documentation</b> about the <b>internals</b> of LuaJIT is still sorely
 230 missing. Although the source code is included and is IMHO well
 231 commented, many basic design decisions are in need of an explanation.
 232 The rather un-traditional compiler architecture and the many highly
 233 optimized data structures are a barrier for outside participation in
 234 the development. Alas, as I've repeatedly stated, I'm better at
 235 writing code than papers and I'm not in need of any academic merits.
 236 Someday I will find the time for it. :-)
 237 </li>
 238 <li>
 239 Producing good code for unbiased branches is a key problem for trace
 240 compilers. This is the main cause for "trace explosion".
 241 <b>Hyperblock scheduling</b> promises to solve this nicely at the
 242 price of a major redesign of the compiler. This would also pave the
 243 way for emitting predicated instructions, which is a prerequisite
 244 for efficient <b>vectorization</b>.
 245 </li>
 246 </ul>
 247 <br class="flush">
 248 </div>
 249 <div id="foot">
 250 <hr class="hide">
 251 Copyright &copy; 2005-2011 Mike Pall
 252 <span class="noprint">
 253 &middot;
 254 <a href="contact.html">Contact</a>
 255 </span>
 256 </div>
 257 </body>
 258 </html>