if it fits into the gideros engine and won't cripple the flexiblity that gideros/LUA has, I would love to see that LuaJIT would be supported. But only, when you guys have nothing else to do.
I'm also very impressed with LuaJIT and waiting the version 2.0 to move out of beta to do some tests on iOS
But only the interpreter mode of LuaJIT can be run on iOS because of the restrictions from Apple (to be more detailed, mprotect function cannot be used). For example, go http://luajit.org/performance_arm.html and select "Lua 5.1.4" with "LuaJIT 2.0.0-beta9 (interpreter)". This will be the speedup on iOS (on average 3x).
Here is an another explanation from Mike Pall (http://luajit.org/install.html): "Note: the JIT compiler is disabled for iOS, because regular iOS Apps are not allowed to generate code at runtime. You'll only get the performance of the LuaJIT interpreter on iOS. This is still faster than plain Lua, but much slower than the JIT compiler. Please complain to Apple, not me. Or use Android. :-p"
If you make it - it'll be awesome. Android version of engine will be faster.. but whatever. Absolute speed of engine will be increased and that's the good reason to use LuaJIT.
I hope you will create the fastest lua engine in the world
Im also very happy with the performance of Gideros, but the more the betther Maybe it could be an Option, at least for the android devices, since there also alot of cheap android devices out with not so much cpu power, for them this could be a good option.
+1 for luaJIT. BTW, luajit2 (even if still called "beta") is at least as stable as v 1.x. And while it is still faster, you get bitop library for free (not sure about FFI - would that work on iOS?).
I would like to see this also pushed forward. This is close to comming out of beta soon and It would be good for a build the community can use (if they want to) to assist in testing so when 2.0 is offically release bam straight into production.
If Gideros integrate LuaJIT, what i could see is total epic awesomeness for sure. Even Gideros could be promoted as using LuaJIT internally, that means really fast lua scripting engine.
@atilim Having LuaJIT would be good (interpreter on iOS, selectable interpreter or JIT on Android) extra speed and bit operations would be handy if free. Please don't say you're waiting for 3.0 now...
Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!). https://deluxepixel.com
@SinisterSoft You're right. I'll start to integrate it at the first opportunity. Sometimes bugs are reported to LuaJIT's email forum but I think it's really stable now.
For example on iPad 3, when there are lots of small sprites moving around, Lua starts becoming the bottleneck instead of graphics drawing. With the introduction of powerful mobile GPUs, now I think LuaJIT becomes more important.
@atilim Besides LuaJIT, there is another candidate to improve the lua performance, llvm-lua. It does AOT (Ahead-of-Time) compiling and supports more platforms/architectures (X86, ARM, PPC) than LuaJIT. AFAIK, rubyMotion use LLVM to compile ruby to machine code for performance improvements. In case you have not started to integrate LuaJIT, what do you think about llvm-lua?
I've read some of the comments online and LuaJIT looks like it's currently better than llvm-lua as it's specific to Lua (llvm-lua is much more general - at least the llvm bit is).
Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!). https://deluxepixel.com
@SinisterSoft It is interesting that today I saw a thread in lua mail list about the comparison between LuaJIT and llvm-lua. It seems that llvm-lua still have its advantages (although not in speed). I remember that I have seen another thread, in which mentioned that llvm-lua is 2 or 3 times faster than lua, while LuaJIT is 2 or 3 times faster than llvm-Lua.
The point is that LuaJIT might be banned by iOS, or can only run interpreter mode (which is also 2 or 3 times faster than lua). In this case, its speed is comparable to llvm-lua without the llvm benefits.
Any way, integrating LuaJIT or llvm-lua will both be a good thing for Gideros. : )
LuaJIT is my first choice, a choice between them by second, just llvm-Lua my third...
Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!). https://deluxepixel.com
Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!). https://deluxepixel.com
@SinisterSoft whoa. interesting. I hope he will continue to develop it.
He made a good choice with LuaJIT's bytecode because it's more capable then Lua's bytecode and LuaJIT's bytecode is portable and can be loaded on any architecture independent of word size or endianess.
Hi, not sure if we could do this. Would an export option be possible to allow LuaJit for android only? Just becasue apple does not allow it's use, does not mean we should be held back.
When we start to use LuaJIT: On iOS, you can expect x2-x3 speedup because of specialized interpreter developed for ARM. On Android, you can expect x20 speedup because of jit-ing.
Comments
But only the interpreter mode of LuaJIT can be run on iOS because of the restrictions from Apple (to be more detailed, mprotect function cannot be used). For example, go http://luajit.org/performance_arm.html and select "Lua 5.1.4" with "LuaJIT 2.0.0-beta9 (interpreter)". This will be the speedup on iOS (on average 3x).
Here is an another explanation from Mike Pall (http://luajit.org/install.html):
"Note: the JIT compiler is disabled for iOS, because regular iOS Apps are not allowed to generate code at runtime. You'll only get the performance of the LuaJIT interpreter on iOS. This is still faster than plain Lua, but much slower than the JIT compiler. Please complain to Apple, not me. Or use Android. :-p"
Likes: SinisterSoft
If you make it - it'll be awesome. Android version of engine will be faster.. but whatever. Absolute speed of engine will be increased and that's the good reason to use LuaJIT.
I hope you will create the fastest lua engine in the world
although gideros'lua byte code is already very, very fast!
www.tntengine.com
Maybe it could be an Option, at least for the android devices, since there also alot of cheap android devices out with not so much cpu power, for them this could be a good option.
Likes: GregBUG, SinisterSoft
www.tntengine.com
Likes: SinisterSoft
I would like to see this also pushed forward. This is close to comming out of beta soon and It would be good for a build the community can use (if they want to) to assist in testing so when 2.0 is offically release bam straight into production.
Please.
Z
Likes: MikeHart, GregBUG
http://www.nightspade.com
)
Likes: phongtt, SinisterSoft
Likes: phongtt
https://deluxepixel.com
For example on iPad 3, when there are lots of small sprites moving around, Lua starts becoming the bottleneck instead of graphics drawing. With the introduction of powerful mobile GPUs, now I think LuaJIT becomes more important.
Likes: SinisterSoft, GregBUG, OZApps, hosamred
Likes: SinisterSoft, vitalitymobile
https://deluxepixel.com
It is interesting that today I saw a thread in lua mail list about the comparison between LuaJIT and llvm-lua. It seems that llvm-lua still have its advantages (although not in speed). I remember that I have seen another thread, in which mentioned that llvm-lua is 2 or 3 times faster than lua, while LuaJIT is 2 or 3 times faster than llvm-Lua.
The point is that LuaJIT might be banned by iOS, or can only run interpreter mode (which is also 2 or 3 times faster than lua). In this case, its speed is comparable to llvm-lua without the llvm benefits.
Any way, integrating LuaJIT or llvm-lua will both be a good thing for Gideros. : )
https://deluxepixel.com
https://github.com/creationix/brozula/
Might make html5 fairly easy once you have added LuaJIT ?
Likes: fxone, phongtt
https://deluxepixel.com
He made a good choice with LuaJIT's bytecode because it's more capable then Lua's bytecode and LuaJIT's bytecode is portable and can be loaded on any architecture independent of word size or endianess.
Likes: SinisterSoft
not sure if we could do this. Would an export option be possible to allow LuaJit for android only? Just becasue apple does not allow it's use, does not mean we should be held back.
Comments?
http://www.nightspade.com
On iOS, you can expect x2-x3 speedup because of specialized interpreter developed for ARM.
On Android, you can expect x20 speedup because of jit-ing.
http://luajit.org/performance_arm.html
Likes: SinisterSoft, Nascode, phongtt, hgvyas123, fxone, jdbc
as soon as @atilim implement LuaJit in Gideros
i *renew* my Gideros Subscription!!!
www.tntengine.com
[troll on]
That way we will have 60x20 = 1200 frames per second
[troll off]
Likes: hgvyas123
zhengyi:tmp zhengyi$ lua main.lua
0.001993
1.652817
zhengyi:tmp zhengyi$ luajit main.lua
0.0018
0.245468
and gideros lua
Uploading finished.
170.259984
172.936773
it seems gideros take more CPU time than normal lua.
Likes: SinisterSoft
https://sites.google.com/site/xraystudiogame