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