status.html 9.7 KB

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