8 ms·
LuaJIT 2.0.5 and 2.1.0-beta3 released
- doomrobo 9y agoDidn't Mike Pall step down sometime last year? It looks like he's made a ton of commits [0] and also made the announcements on the mailing list [1]. Anyways, congrats on the new release! [0] https://github.com/LuaJIT/LuaJIT/commits/master https://github.com/LuaJIT/LuaJIT/commits/master [1] https://www.freelists.org/archive/luajit/05-2017 https://www.freelists.org/archive/luajit/05-2017
- corsix 9y agoThe commit author doesn't tell the whole story: the long description on most of the recent commits mention somebody else.
- sillysaurus3 9y agoI hooked up LuaJIT to emacs for fun. Emacs recently released a new module system where you can build DLLs that are loaded dynamically: http://diobla.info/blog-archive/modules-tut.html http://diobla.info/blog-archive/modules-tut.html Getting LuaJIT to work on 64-bit OS X required building a custom emacs with linker flags -pagezero_size 10000 -image_base 100000000. This is unfortunate since obviously users will not take the time to build an emacs with custom linker flags. But more generally, this is an issue any time you want to embed LuaJIT in an application plugin rather than the application itself. There's a bunch of scattered info about the issue: https://gist.github.com/nddrylliog/8722197 https://gist.github.com/nddrylliog/8722197 http://hacksoflife.blogspot.fr/2012/12/integrating-luajit-with-x-plane-64-bit.html http://hacksoflife.blogspot.fr/2012/12/integrating-luajit-wi... https://en.blog.nic.cz/2015/08/12/embedding-luajit-in-30-minutes-or-so/ https://en.blog.nic.cz/2015/08/12/embedding-luajit-in-30-min... http://luajit.org/install.html http://luajit.org/install.html I was hoping there might be a way of sidestepping the issue somehow. If anyone has any ideas, it would be appreciated. LuaJIT has some nice speed improvements compared to standard Lua, but more importantly it has a pretty amazing FFI library. The C declaration parser in particular is valuable. (Yes, I know it's pointless to hook LuaJIT to emacs. It's mostly a "just because" project.)
- corsix 9y agoThe solution is included in 2.1.0-beta3: "LuaJIT for x64 can optionally be built for LJ_GC64 mode by enabling the -DLUAJIT_ENABLE_GC64 line in src/Makefile or via 'msvcbuild.bat gc64'." "This mode removes the 32 bit limitation for garbage collected memory on 64 bit systems." [0] [0] https://www.freelists.org/post/luajit/LuaJIT210beta3 https://www.freelists.org/post/luajit/LuaJIT210beta3
- sillysaurus3 9y agoPerfect! Thank you.
- daurnimator 9y ago> I was hoping there might be a way of sidestepping the issue somehow. If anyone has any ideas, it would be appreciated. LuaJIT has some nice speed improvements compared to standard Lua, but more importantly it has a pretty amazing FFI library. The C declaration parser in particular is valuable. Why use LuaJIT over plain Lua here? I can't imagine that you need the extra speed in a text editor. The ffi is available for normal lua too: https://github.com/facebook/luaffifb/ https://github.com/facebook/luaffifb/
- camperman 9y agoBecause it's so easy. From the manual: So here's something to pop up a message box on Windows: local ffi = require("ffi") ffi.cdef[[ int MessageBoxA(void *w, const char *txt, const char *cap, int type); ]] ffi.C.MessageBoxA(nil, "Hello world!", "Test", 0) Bing! Again, that was far too easy, no? Compare this with the effort required to bind that function using the classic Lua/C API: create an extra C file, add a C function that retrieves and checks the argument types passed from Lua and calls the actual C function, add a list of module functions and their names, add a luaopen_* function and register all module functions, compile and link it into a shared library (DLL), move it to the proper path, add Lua code that loads the module aaaand ... finally call the binding function. Phew!
- 9y ago
- vvanders 9y agoIf you want to get an idea just how good LuaJIT is take a look at these benchmarks against the stock VM(which is already good) [1][2] We used to run Lua on a 300MHz MIPS processor and it was impressive in how well it worked on that constrained platform(only 8mb is system ram, of that Lua ran in a fixed 400kb block). [1] - http://luajit.org/performance_x86.html http://luajit.org/performance_x86.html [2] - http://luajit.org/performance.html http://luajit.org/performance.html
- TillE 9y agoThe most impressive part of LuaJIT is that its non-JIT'd interpreter is several times faster than Lua in benchmarks. Great for platforms like iOS which don't allow code modification at runtime.
- shalabhc 9y agoFor an editor built from the ground up using LuaJIT see https://howl.io https://howl.io [/plug]
- sillysaurus3 9y agoThe docs are pretty. What do you use to generate e.g. https://howl.io/doc/spec/interact_spec.html https://howl.io/doc/spec/interact_spec.html ?
- shalabhc 9y agoThank you. I believe the tests are converted to HTML by a custom Ruby script: https://github.com/howl-editor/howl/blob/master/site/bin/spec2html https://github.com/howl-editor/howl/blob/master/site/bin/spe... The manual and API docs are hand written in markdown.
- stevekemp 9y agoIf we're plugging things that can benefit from LuaJIT: I wrote a console-based mail-client, kinda like mutt, which uses Lua for all the scripting and UI. https://lumail.org/ https://lumail.org/ New release will be out in a few days.
- omaranto 9y agoThe documentation could use a section explaining what Howl has to offer over other text editors than are extensible using Lua, such as Textadept (https://foicica.com/textadept/ https://foicica.com/textadept/).
- shalabhc 9y agoGood point. It's hard to highlight certain differences because it's a very different editor. In general I think Howl offers a better API and a more keyboard centric UI compared to Textadept. Most commands are operated via the command line which offers auto-complete (vs operating via the menu bar, with custom dialog boxes for each command). Howl also doesn't use Scintilla (Textadept does) and is not subject to Scintilla's limits.
- fosk 9y agoLuaJIT is such an amazing piece of software - apparently to such an extent that only Mike Pall fully understands some of its internals. Besides being much faster than the official Lua VM, it offers extended features like the FFI library [1]. Kong[2] uses it extensively, by leveraging the underlying OpenResty[3] framework. [1] http://luajit.org/ext_ffi.html http://luajit.org/ext_ffi.html [2] https://github.com/Mashape/kong https://github.com/Mashape/kong [3] https://github.com/openresty/lua-nginx-module https://github.com/openresty/lua-nginx-module
- placebo 9y ago> LuaJIT is such an amazing piece of software - apparently to such an extent that only Mike Pall fully understands some of its internals Fully agree about the awesomeness of LuaJIT and incredible capabilities of Mike Pall, but also the reason I've stopped considering using LuaJIT for projects that should be "future proof". I think that depending on technology which can only be maintained by one genius is too much of a risk.
- leafo 9y agoLuaJIT powers OpenResty[1] which powers my web framework Lapis[2] which powers my company itch.io[3]! (wow that's a mouthful) Anyway, it's a stack I'm really happy to be using. Asynchronous IO without any code nesting. I wrote more about the benefits here: http://leafo.net/posts/itchio-and-coroutines.html http://leafo.net/posts/itchio-and-coroutines.html [1] https://openresty.org/en/ https://openresty.org/en/ [2] http://leafo.net/lapis/ http://leafo.net/lapis/ [3] https://itch.io/ https://itch.io/ I also made web server infrastructure for the Lua package manager LuaRocks in the same stack: https://luarocks.org https://luarocks.org Source is on github: https://github.com/luarocks/luarocks-site https://github.com/luarocks/luarocks-site Lua (especially with LuaJIT) is a great choice for web development.
- tiffanyh 9y agoLove Lapis. Question, since Lapis just transcode Moonscript into Lua to be used with OpenResty - why is Lapis so much slower than raw OpenResty/Lua? https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
- killin_dan 9y agoBecause the lua code moonsript emits is inherently slower.
- tiffanyh 9y ago>> "inherently slower" What's "inherent" in moonscript that makes it slower?
- meowface 9y agoNot necessarily. Like CoffeeScript, it depends on what features you use.
- leafo 9y agoNot really, the code mapping is very straightforward and generally has no performance degradation. There are some language constructs that are implemented in a way that can create anonymous functions in order to convert statements into expressions. Future versions of MoonScript can do a better job to eliminate those. If you're aware when they're generated you can avoid them by writing as you might do in Lua. Realistically though, the performance difference is negligible in comparison to all the other things that might happen in your average web request.
- i_feel_great 9y agoDon't forget the Not Yet Implemented features: http://wiki.luajit.org/NYI http://wiki.luajit.org/NYI Edit: By the way, can someone explain why ipairs() is implemented, but not pairs()?
- haberman 9y agoThose are just features that aren't JIT compiled. They are still implemented, in the sense that LuaJIT fully supports them in the interpreter, so you can use them in LuaJIT programs. I'm guessing that pairs() is not JIT-compiled because iterating over a hash table involves logic that is significantly more complicated than iterating over an array (like ipairs()).
- trynumber9 9y ago>By the way, can someone explain why ipairs() is implemented, but not pairs()? https://www.freelists.org/post/luajit/LuaJIT-21-status-and-sponsorships,15 https://www.freelists.org/post/luajit/LuaJIT-21-status-and-s...
- diegobernardes 9y agoReally can't understant why Lua isn't more used. It play the same role as Ruby, Python and JS and is very fast, at least, much more then Ruby and Python.
- spc476 9y agoBatteries are not included in Lua. To do most anything interesting requires third party libraries (like directory manipulations, network, etc).
- corysama 9y agoYep. Lua's small (and removable) standard library makes it really great for embedding, not so great standalone.
- mmjaa 9y agoBut when you need batteries, you just install luarocks and move on with it.
- veli_joza 9y agoIt's not that libraries are not available, it's that they are not _standard_. Python has much healthier and more coherent community partially because everybody started out with same carefully chosen building blocks. With Lua you either build your own or bring in dependencies from libs and frameworks. Regardless, I'm enjoying Lua more and more and it's becoming my go-to language for prototyping and exploring concepts. The code just flows more naturally than in other languages.
- mmjaa 9y agoI think there is something else to this. Most highly productive Lua applications I've seen, been involved in, &etc., are bound to system-level libs/api's, etc. So the thing about Lua as a scripting language like Python, is that you can use it like that. But the major power of the language is when you apply it by glom'ing it into some bundle of C/C++ libraries that are, indeed, BYO-batteries... Like, Lua is bring-your-own battery, true. For everything else, there's Penlight/luarocks, though.
- bakery2k 9y agoLooking at the LuaJIT changelog [1], it's interesting how many bugs need fixing in each version: 20 in 2.0.5 and 32 in 2.0.4. Compare this with PUC Lua [2], which seems to have very few bugs: only 4 in 5.3.3 and 3 in 5.3.2. LuaJIT and PUC Lua appear to be very similar superficially ("LuaJIT is Lua, but fast"). The relative bug counts reinforce the fact that in the details, the two implementations are very different - for example, LuaJIT uses a lot of assembly language while PUC Lua is pure C89. The advantages of LuaJIT over PUC Lua seem to be performance and its FFI. I thought PUC Lua's only advantage was portability, but perhaps PUC Lua is also a generally more "correct" implementation? [1] http://luajit.org/changes.html http://luajit.org/changes.html [2] https://www.lua.org/bugs.html https://www.lua.org/bugs.html
- jshmrsn 9y agoNot only does LuaJIT have platform-specific assembly in its source, but a big part of its advantage over PUC Lua is of course that it's compiling down to machine language on the fly. And that process is also platform specific. I have definitely seen bug fixes along the lines of "fix X for Y platform's JIT output." I have also seen non-jit-related bugs impact us in production. BUT, LuaJIT really is FASTER. Even when JIT cannot be used (e.g. on iOS), it can still be several times faster than PUC Lua. And that speed is a real killer feature for us. Otherwise, we'd just use JavaScript.
- rlp 9y agoDo you find LuaJIT much faster than a JavaScript engine like V8? That used to be true, but I was under the impression that V8 had basically caught up (unless you need to make a lot of FFI calls, since LuaJIT is heavily optimized for that).
- jshmrsn 9y agoI may be behind the times, but last I checked there was no way to use JITed JavaScript in iOS apps. Or maybe you could put JS in a hidden webview, but bridging to native was extra slow with this approach? While LuaJIT can't be JITed either on iOS, I think the general consensus is that non-jit Lua is faster than non-jit JS. I do a lot of bridging Lua to native, and that's another area where Lua is often considered more efficient. Again, these thoughts may be out of date.
- rweichler 9y agoBuild system in pure Lua: https://github.com/rweichler/aite https://github.com/rweichler/aite 3DS port: https://github.com/rweichler/luajit-3DS https://github.com/rweichler/luajit-3DS iOS runtime inspector: https://github.com/rweichler/lucy https://github.com/rweichler/lucy Cydia alternative: https://github.com/rweichler/jjjj https://github.com/rweichler/jjjj And this is just stuff by me, some schlep. LuaJIT is so underrated it's kind of sad.
- rkeene2 9y agoI'm still unable to use LuaJIT because the build system makes an incorrect and silly assumption that code compiled during the build by the build compiler had the same executable properties as the code compiled during the build by the host compiler, leading to the situation where: repeatable builds don't work, and you can't compile for Linux/x86_64 from Linux/x86 or Linux/arm. It is one of very few packages broken this way, along with basically only XFree86 4.8.0 :-(