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