LuaJIT-compiled LÖVE

[slime]

I noticed that there is a Löve 0.7.0 windows beta compiled for LuaJIT. It would be nice if compiled LuaJIT builds of version 0.7.0 (and the upcoming 0.7.1) were provided for those of us not knowledgeable enough to do it ourselves. Unless there's some technicality I'm missing that makes it unfeasable.

[bartbes]

Well, technically LuaJIT is still unstable, and in fact the first time I ran love linked against luajit it crashed for no reason.
But if there's someone willing to build it with luajit, I won't be holding you back.

[TechnoCat]

LuaJIT 2.0 or 1.1?

EDIT: Okay, so building LuaJIT on Windows is no problem, but including it into LOVE I'm not finding as straight-forward as it probably is. Any help appreciated.

[johnson_lin]

Hello, I just tried building Love2D against dynamically linked LuaJIT2-git HEAD version, and most things looked just fine. I tried a bunch of Love2D games & examples out there and not a single one crashed. Just some of the origin point of images seem a little off (e.g the rotating LOVE icon in the no-game demo would move around a little bit, instead of staying still; and the titles and texts of Ten-Second War are a bit off too. I didn't notice any other problems.)

I've modified some really basic example from Love2D 0.7 to make sure the JIT is on, and even the newly implemented FFI functions in the git HEAD version of LuaJIT2 can co-work with Love2D, too. I tried to pop up a Windows Message Box in the particle.love example when I press a key... I know this isn't of any use, just to make sure it works. The real benefit would be the ability to use ctype & cdata from the LuaJIT FFI. However the FFI isn't nearly complete yet, as the author(Mike Pall) says.

FYI: http://repo.or.cz/w/luajit-2.0.git/blob ... t_ffi.html

There's already a noticable performance gain when I test Taehl's Isome engine, as the FPS is boosted around 40% when using LuaJIT2. Considering the dominant performance threshold in Isome is rendering all the terrain blocks, which is a device I/O block that won't be helped by JIT compilation whatsoever, 40% FPS gain is very, very significant IMHO. To my knowledge the main loop of Love2D framework is written in lua itself (boot.lua) so the JIT gain should come from places like this.

And it's not really too hard to make Love2D work with LuaJIT --

1. The first thing would be link Love2D against Lua dynamically. On Windows I use lua\\etc\\luavs.bat to build the official Lua 5.1.4 package. It will build Lua 5.1.4 dynamically by default, and then you replace the lua lib in the Love2D SDK (from love2d.org/sdk) with the newly-built one (this one should be relatively small) and then rebuild Love2D (I use bitbucket HEAD ver.) with the rest of the SDK. I don't use Lua for Windows because that's rather confusing.

Reason:
Since linking with LuaJIT2 statically on Windows (which is my only platform, for now) is already documented by Mike Pall himself as "no good" And both LuaJIT1 and 2 are ABI-compatible for a drop-in replacement for vanilla Lua on most major OS environment, so this is the method I use.

2. Your Love2D should now complain for missing the lua dynamic library if you don't provide that when you boot up love.exe. So provide that to love.exe too. Lua for Windows named it lua5.1.dll but with etc\\luavs.bat in the official package you'll get a lua51.dll. Just simply provide that to love.exe, the naming-convention of "lua5.x.dll" is deprecated in the next version of Lua anyway. This step is not necessary, just to make sure your Lua is linked dynamically without problem (And it should.)

3. Build LuaJIT. It can be LuaJIT 1.1.6 stable or LuaJIT 2-beta5 or LuaJIT git HEAD ver. It's even easier than the vanilla Lua package :p Just simply 'make' or use msvcbuild.bat in the src folder. I suggest LuaJIT2 because that's the one which really made a difference, and it's actually quite stable IMHO.

4. Now just replace the dynamic library file you provided to love.exe. Try to print some JIT status stuff (see LuaJIT2 API) on the screen or on the console to make sure it's working and not an illusion :p You could even try the FFI functions. Now you can start benchmarking. =)

As a last note, Qualcomm is sponsoring Mike Pall to port LuaJIT2 onto ARM.
FYI: http://article.gmane.org/gmane.comp.lan ... eral/74072

The downside of LuaJIT2:

1. Not "Bytecode-compatible." which is usually not very important.. I guess. API plus ABI compatible is already good enough for nearly all the drop-in replacements, provide your CPU architecture supports what the JIT engine needs.

2. Binary size is bigger. With LuaJIT2 FFI library, the binary will be twice as the size of the vanilla Lua. It's still very small though. (around 300KiB on Windows, built with msvc)

3. Won't fully support Lua 5.2 immediately. However some aspects of Lua 5.2 are already built into LuaJIT2. Some people might take this into consideration.

4. Due to LuaJIT2's optimizations, some optimization techniques for vanilla Lua might be counter-productive. This should be taken into consideration as well, if you plan to run your Lua / Love2D applications on platforms that still don't have LuaJIT2.
FYI: http://lua-users.org/lists/lua-l/2011-01/msg00978.html (in the middle part of the post)


Quite a post.. phew. =)

[Taehl]

Someone actually used Isome for something?

Excellent post, though. Very useful and informative.

[slime]

I compiled an intel-only OSX LuaJIT (2.0.0-beta6) Löve build: http://dl.dropbox.com/u/4214717/LoveJIT.zip

Compiling against a dynamic library kept giving me the error

Code: Select all

dyld:  Library not loaded: libluajit.so

so i had to use a static one.

[johnson_lin]

Not sure how you built it, but that error message seemed like you didn't provide the dynamic library in the related PATH(s).

Although, The only downside of static-build I can think of is not being able to rebuild/update only the Lua/LuaJIT part, and then drop-in. You'll have to rebuild LÖVE every time. For benchmarking purpose I used to change the dll (on windows) back and forth very often between Lua's dynamic lib and LuaJIT's dynamic lib to check for the differences.