5 ms·
It's nice and all, but I'll be over here using LuaJIT.
by fullstop 7y ago
It's nice and all, but I'll be over here using LuaJIT.
- sam_lowry_ 7y agowhy?
- lytedev 7y agoPresumably speed?
- cosarara 7y agoBecause it's fast.
- tyingq 7y agoThe performance difference is pretty stunning. https://luajit.org/performance_x86.html https://luajit.org/performance_x86.html
- Fnoord 7y agoThat is comparing with 5.1.5, not 5.3 or 5.4 beta. (The default of comparing x86-32 also does not make sense to me, YMMV.)
- tyingq 7y agoI couldn't find a way to deep link to the x64 numbers, but they aren't significantly different. Hopefully they update it with a more current Lua version.
- johnisgood 7y agoIndeed. Mike Pall blows them out of the water single-handedly. I wonder if Lua developers have learnt anything from him with respect to performance. I would like to see how Lua 5.4.0 would perform in comparison.
- corysama 7y agoThe Roblox team is making a new Lua interpreter (not JIT) from scratch with a focus on performance. Don’t think it’ll be open source though.
- hugomg 7y agoIt is no surprise that the benchmarks on the LuaJIT website are going to show it ahead of PUC-Lua, is it? In truth the performance comparison is a bit more complicated than that. :) For a pure Lua comparison LuaJIT is typically going to beat Lua by a large margin. For code that can be JIT compiled you might see ~10x performance improvements and for code that doesn't you might still see around a ~2x improvement because the LuaJIT interpreter is written in hand-crafted assembly language (PUC-Lua sticks to portable and standards-compliant C90). But things get a bit more complicated if you add foreign C code into the mix. Under LuaJIT, the JIT compiled code that uses the LuaJIT FFI interface is the fastest, but interpreted code using the FFI is slower than interpreted code using the traditional Lua-C interface, and can even be slower than PUC-Lua using the traditional Lua-C interface. This means that when you are using LuaJIT you need to be very careful to make sure that your code is the sort of code that can be JIT compiled. If you hit a "not yet implemented" feature you can have a big performance degradation. ------ Nevertheless, Lua 5.4 has brought significant performance improvements compared to Lua 5.3, specially in integer operations (including for loops). Another big change was that the `#` is now faster. For example, on my machine the following loop runs in 1.96 seconds in Lua 5.3, in 1.26 seconds under LuaJIT, and in 0.96 seconds in Lua 5.4 local a = {} for i = 1, 1e7 do a[#a +1] = i end print(#a) The new generational garbage collector is also a very big improvement. I've measured a 1.5x speedup on some GC-dominated workloads, where the final result was that Lua 5.4 would even edge out LuaJIT, which is still using the old incremental collector.
- dottrap 7y ago> I wonder if Lua developers have learnt anything from him with respect to performance. It cannot be emphasized enough that PUC-Lua and LuaJIT have different goals. One goal for PUC-Lua is that it must be portable everywhere and be implementable in pure ANSI C (no platform or architecture specific calls). LuaJIT in contrast contains much handwritten assembly for the specific architectures it supports. PUC-Lua also cares deeply about interoperating with C and hence why the Lua-C interface is formally part of the language spec, and as the parent thread mentioned, LuaJIT using the traditional Lua-C interface can be really slow. That said, PUC-Lua has learned a lot from Mike Pall. It was Pall that helped them get fully yieldable coroutines across pcall boundaries. I'm sure Pall's lengthy analysis of unimpressive garbage collection performance in both Lua 5.1 and LuaJIT was read by all of them and a motivation for them to try the generational garbage collector now finally working in 5.4. But finally, there is a new project called Pallene (not being pedantic, formerly known as Titan). It is inspired by all the lessons of LuaJIT. The name 'Pallene' is a nod to Mike Pall. Pallene is a statically typed sister language to Lua that is designed for performance and easy C/Lua bridging, but in a way that doesn't bring in all the downsides of JIT. The language is glued at the hip to Lua so there is also easy interoperability between Pallene and Lua code. Pallene introduces static types not for the sake of type safety, but for the purpose of inferring what things can be optimized. Pallene brings in a AOT compiler into the mix and generates optimized binaries. But these binaries also look like any other Lua/C native library so they are callable from normal Lua too and the user doesn't know if they were implemented in C or Pallene. Pallene was previously discussed on HN here: https://news.ycombinator.com/item?id=18038619 https://news.ycombinator.com/item?id=18038619 Also look for the original Titan talk from one of the Lua Workshops a few years ago.
- fullstop 7y agoI use FFI and LuaJIT is significantly faster on my embedded platform. Also, you can yield in coroutines in places where you can not with the standard Lua VM, such as across pcall, xpcall, iterators, and in metamethods. It is fantastic software.
- tyree731 7y agoOpenresty
- Kiro 7y agoWhy wouldn't you be able to use this with LuaJIT? I thought LuaJIT was just a compiler for the Lua language.
- ourlordcaffeine 7y agoLuaJit only conforms to Lua 5.2, so new features in Lua 5.4 would not work
- fullstop 7y agoLuaJIT is an entirely different VM. It is binary compatible with Lua 5.1.x modules (shared libraries) and can run most Lua 5.1 and 5.2 code. A good amount of the 5.2 changes, specifically those which do not break 5.1 code, have been added to the VM.
- vanderZwan 7y agoLuaJIT officially supports up to Lua 5.1.x, mainly due to Mike Pall not liking all changes to the language that followed https://www.freelists.org/post/luajit/Port-bitop-to-53,1 https://www.freelists.org/post/luajit/Port-bitop-to-53,1