Page 1 of 1
Love2d LUA JIT 2.0
Posted: Fri Jun 14, 2013 11:26 pm
by RedHot
Has anyone ever experienced any problems with Love2d 0.8 compiled for lua jit 2.0 ? I have just recendly found out about this option and I got a 10x speed boost on my math operations. Works like a charm.
Any downsides of using Love2d are ok as well.
Re: Love2d LUA JIT 2.0
Posted: Fri Jun 14, 2013 11:54 pm
by Jasoco
Nope. The speed improvement is amazingly useful in my 3D project where I need to manipulate thousands of points every frame.
Re: Love2d LUA JIT 2.0
Posted: Sat Jun 15, 2013 4:22 am
by Davidobot
Unrelated: what is all this Lua JT stuff I've been hearing about recently?
Re: Love2d LUA JIT 2.0
Posted: Sat Jun 15, 2013 5:00 am
by NightKawata
Davidobot wrote:Unrelated: what is all this LuaJT stuff I've been hearing about recently?
Pretty much this.
This too:
!!!!!!!!!
As far as I'm aware, there aren't many problems switching vanilla love for jit love. Switching from jit to vanilla might be an issue if you use the bit library that jit supports (or ffi), but other than that, eh.
Only real downside to using Love2D involves the libraries, as in publicly telling someone that you used a library like AnAL/SECS/hump/hardon collider (though the only of the four I use of those would be SECS), due to the rather... creative... minds of the authors. (Great libs, but don't google most of them!
)
Re: Love2d LUA JIT 2.0
Posted: Sat Jun 15, 2013 5:05 am
by scutheotaku
Davidobot wrote:Unrelated: what is all this Lua JT stuff I've been hearing about recently?
JIT = "just in time," which, in this context, means "just in time compilation."
From Wikipedia:
In computing, just-in-time compilation (JIT), also known as dynamic translation, is a method to improve the runtime performance of computer programs based on byte code (virtual machine code).
In a bytecode-compiled system, source code is translated to an intermediate representation known as bytecode. Bytecode is not the machine code for any particular computer, and may be portable among computer architectures. The bytecode may then be interpreted by, or run on, a virtual machine. The JIT compiler reads the bytecodes in many sections (or in full, rarely) and compiles them dynamically into machine language so the program can run faster. Java [for example] performs runtime checks on various sections of the code and this is the reason the entire code is not compiled at once.[2] This can be done per-file, per-function or even on any arbitrary code fragment; the code can be compiled when it is about to be executed (hence the name "just-in-time"), and then cached and reused later without needing to be recompiled.
In contrast, a traditional interpreted virtual machine will simply interpret the bytecode, generally with much lower performance. Some interpreters even interpret source code, without the step of first compiling to bytecode, with even worse performance. Statically compiled code or native code is compiled prior to deployment. A dynamic compilation environment is one in which the compiler can be used during execution. For instance, most Common Lisp systems have a compile function which can compile new functions created during the run. This provides many of the advantages of JIT, but the programmer, rather than the runtime, is in control of what parts of the code are compiled. This can also compile dynamically generated code, which can, in many scenarios, provide substantial performance advantages over statically compiled code[citation needed], as well as over most JIT systems.
Source:
http://en.wikipedia.org/wiki/Just-in-time_compilation
As far as LuaJIT in particular:
http://luajit.org/luajit.html
http://luajit.org/performance_x86.html