LuaJIT

[Luiji]

I'm going to do some more research on LuaJIT and post the results here.

EDIT: Results follow:
----------
So, LuaJIT is really easy to use. Actually, LOVE devs don't have to do anything. Anybody can download the LuaJIT library and replace the liblua library in the LOVE installation, and your done!

LuaJIT currently supports x86 and x64, so what we should do is repackage the x86 and x64 packages with LuaJIT instead of Lua, and it's that simple! Yay! No coding has to be done!

[Lap]

Have you done any practical tests running your games with luaJIT? I'm interested in seeing outside of standard test situations.

[Elvashi]

Before we get too excited, I know from reputation that luaJIT is not perfectly compatible with the reference implementation (i.e., what we are currently using). There will be incompatibilities and quirks, and we should look into what they are before we rush to create inconsistencies between JIT and non-JIT capable platforms.

[bmelts]

Luiji: we know all that, really.

A few notes on LuaJIT:

LÖVE supports more architectures than just x86 and x64. For those architectures, we'd have to have some way of falling back to regular Lua. Including both with LÖVE isn't really a viable option.

It's not Lua. Not exactly, anyway. There are inconsistencies with vanilla Lua, inconsistencies that could lead to platforms without LuaJIT behaving differently, and it's very important that LÖVE behave consistently across platforms. (basically, what Elvashi said.)

It probably won't make much of a difference. Speeding up Lua performance is well and good, but LÖVE spends the vast majority of its time in non-Lua code, particularly graphics routines. If you're doing a lot of stuff with the standard Lua library in your game, you may well see some improvement from using LuaJIT, but I'm dubious that there'd be substantial performance improvements with most games. If anyone feels like taking it upon themselves to run some benchmarks, it'd be interesting to see just how much performance improves.

[Luiji]

The point is is that we simply distribute x86/64 distrobutions withe the lua51 library from LuaJIT instead of Lua standard's. This all has to do with distribution.

I'll run those benchmarks from that other user with JIT/non-JIT when I get time.

Quirks make me not like the idea. Maybe we should just keep LuaJIT in mind for when those are worked out.

[Elvashi]

The point is that LuaJIT is subtly but critically different from the reference implementation, and one of loves goals is to be a consistent platform. Accepting differences, any differences, between love distributions is not a decision to be made lightly.

Also, Lua is compiled into love, there's no "lua51.{dll,so}" to replace in the distribution packages. not last I checked, anyway.

[bartbes]

Ahem, I just read the documentation for LuaJIT and it says that it can be used as a "drop-in replacement for standard Lua", implying we don't have to do any coding, and simply replace the libraries...

That still doesn't make it easy, as it says it's a replacement, it's a custom build of lua, and we probably still want to support standard lua, and the both of them at once are going to be hell.

[Luiji]

Okay, let me explain in the cleanest possible way I can.

More towards recently, LuaJIT made Lua51.dll/.so which can simply replace the Lua51.dll/.so for Lua, as long as you are not embedding the program using .a. If you embed using .a, then there are a bit more complication. (.a is a file for static linking.)

It's not a replacement meaning that you must modify your code in any way, it just means that you install it instead of Lua standard.

LuaJIT runs plain Lua code, so any Lua code embedded into LOVE would be in no way effected. In fact, LuaJIT explicitly says that it is binary compatible of Lua standard, so it can even run files generated by LuaC.

The only reason for not using LuaJIT that has been stated that is actually in any way true is the fact that LuaJIT's implementation has quirks that cause incompatibilities with Lua standard, meaning that LOVE files would be less portable, meaning that this idea should not be implemented until LuaJIT runs out of quirks (which may take awhile).

[bartbes]

Or unless we can use both, which a dll with the same name doesn't make easier...

[Luiji]

OK, I'm going to make a tutorial on the Wiki when I get time to prove how it's all a matter of distribution.