How about new gc , and memory limit in 64bit platform ? 2013/5/22 Mike Pall <mike-1305@xxxxxxxxxx>: > LuaJIT 2.1 Status > ================= > > Development on LuaJIT 2.1 is currently underway. Since a lot of > the code is still in flux, it'll remain in alpha status for now. > Many more improvements will go into 2.1 before it becomes final. > > Currently, LuaJIT 2.1 is only available via the 'v2.1' branch of > the git repository. If you want to check it out, please refer to > the instructions at: http://luajit.org/download.html > > Here are the main changes in LuaJIT 2.1 as of today: > > * The x87 FPU support for the interpreter has been removed. > > For LuaJIT 2.0, x86 CPUs without SSE2 only worked in interpreter > mode and the JIT-compiler was disabled. LuaJIT 2.1 won't run at > all on a CPU without SSE2 support. > > The 32 bit x86 port of LuaJIT 2.1 now offers consistent IEEE-754 > semantics, just like the other ports. And all implicit conversions > of FP numbers to integers round towards zero. > > * Several standard library functions have been replaced with > builtin bytecode. > > These library functions have been rewritten in Lua -- the source > code can be found inline in the corresponding modules (lib_*.c). > The code is mangled, pre-compiled to bytecode and embedded into > the binary. This saves space, simplifies compilation and avoids > NYI cases that couldn't be resolved otherwise. > > Most of the changes shouldn't have any user-visible impact > (string.len() etc.). But you may notice some former NYI cases > are compiled, e.g. table.foreachi() or table.remove() (in 2.0, > only the 'pop' operation was compiled). > > More builtins will follow. A bigger item on my TODO list is a > Lua rewrite of the package library (package.*, require, module). > > I should note that replacing a C builtin with a Lua builtin does > _not_ cause a slowdown, even on platforms where the JIT-compiler > has to be disabled (iOS, consoles). The overhead of a series of > Lua/C API calls from C code is comparable to the overhead of > bytecode dispatch. The core of the bytecode interpreter and many > important builtins are written in heavily optimized assembler. > Of course, once JIT-compiled, both overheads can be eliminated. > > * String formatting semantics have been unified across platforms. > > Both Lua 5.x and LuaJIT 2.0 show platform-dependent behavior for > the integer formats %d, %u, %o and %x of string.format(). > Basically, you got 32 bit wide conversions on some platforms and > 64 bit conversions on others. string.format("%d", 2^32) returned > either "0" or "4294967296" or an undefined result. Rounding was > similarly unpredictable. > > LuaJIT 2.1 offers consistent 64 bit conversions for all integer > formats. The unsigned formats also accept and convert negative > numbers and re-interpret them as unsigned 64 bit integers. > > One potential pitfall for users is that > string.format("%x", -1) > previously returned "ffffffffffffffff" on some LuaJIT 2.0 > platforms and "ffffffff" on others. You may need to adapt your > code if it relies on the latter result. > > Note that the Lua BitOp manual has warned about this behavior of > %x with signed inputs. The suggested, portable workaround is > to use bit.tohex(), which guarantees fixed length output. > > On a related note, the %s and %c formats now handle embedded NUL > characters. > > * All bit.* functions can now operate on 64 bit FFI cdata values. > Details below. > > * String buffers and string operations have been improved. > Details below. > > > Sponsorship for 64 bit Bitwise Operations > ========================================= > > A corporate sponsor, who wishes to remain anonymous, has sponsored > the development of 64 bit bitwise operations for LuaJIT 2.1. > > The rules for bitwise operations follow the general rules for > arithmetic operations on FFI data types: 64 bit integer arguments > are 'sticky'. E.g. bit.band(0x16LL, 5) returns 4LL (a cdata > number, not a Lua number). > > The only exception is bit.tobit(), which truncates to a signed > 32 bit integer and returns a plain Lua number -- just like the > 32 bit bitwise operations. > > The default output size for bit.tohex() is 8 hex digits for plain > numbers and 16 hex digits for FFI cdata numbers. > > For the exact semantics, point your browser to the file > doc/ext_ffi_semantics.html#cdata_arith > in the v2.1 branch. > > > Sponsorship for Performance Improvements > ======================================== > > I'm happy to announce that CloudFlare Inc. https://www.cloudflare.com/ > is sponsoring various performance improvements for LuaJIT 2.1. > CloudFlare is operating one of the world's largest deployments of > nginx + LuaJIT. As you can imagine, at this scale, every fraction > of a microsecond that can be shaved off for each request has a > significant impact. > > I'm working closely together with Yichun Zhang (agentzh) at > CloudFlare to identify and fix any remaining bottlenecks. The > current focus is on string operations. Many of these are NYI items > in LuaJIT 2.0, causing fallbacks to the interpreter. > > These items have already been improved in LuaJIT 2.1 (git): > > - Reorganize string buffer management and tune string ops. > > - JIT-compile string concatenations ('..' operator, CAT bytecode). > > - JIT-compile the following library functions: > string.char(), string.rep(), string.reverse(), string.lower(), > string.upper(), table.concat(), bit.tohex() > > - Reorganize and speed up string formatting and remove most > dependencies on sprintf(). FP number formats still use sprintf(). > > - Partially JIT-compile the following library functions: > string.format() -- Not %p, not for non-string args to %s. > string.find() -- Only for fixed string searches (no patterns). > > This means that all string.* functions are now compiled, except > for string.dump() (not helpful to compile) and pattern matches. > http://wiki.luajit.org/NYI has been updated accordingly. > > More improvements coming, as we go along. > > --Mike > -- http://blog.codingnow.com