LuaJIT maintainer's take on Apple/Clang
1–10 of 27 posts
Re: LuaJIT maintainer's take on Apple/Clang
#2This is 6 months old on a version of XCode that is now two versions out of date. Is there a reason it's being brought up now?
Re: LuaJIT maintainer's take on Apple/Clang
#3You can browse this with dates and with 7 less ads per page here:
http://lua-users.org/lists/lua-l/2012-02/msg00597.html
Re: LuaJIT maintainer's take on Apple/Clang
#4am I missing something or should the title be "LuaJIT linker error on iOS" and the current version of XCode is 4.4 not 4.2 mentioned.
Re: LuaJIT maintainer's take on Apple/Clang
#5Fixed-point integer math is faster than floating, but not by much anymore.
Re: LuaJIT maintainer's take on Apple/Clang
#6So all ARM processors that Apple uses have the real hardware floating point and LuaJit (which is a very cool engineering feat) which is supposed to speed up the execution of the Lua scripts still uses the "soft-only" calls. How much that slows down LuaJit? I guess the "soft calls" can be redirected to the pure hardware instructions? How big is the speed penalty vs. using the hardware directly?
Re: LuaJIT maintainer's take on Apple/Clang
#7So all ARM processors that Apple uses have the real hardware floating point and LuaJit (which is a very cool engineering feat) which is supposed to speed up the execution of the Lua scripts still uses the "soft-only" calls. How much that slows down LuaJit? I guess the "soft calls" can be redirected to the pure hardware instructions? How big is the speed penalty vs. using the hardware directly?
I think luajit can generate jit code suitable for the current cpu/arch it's running under, no matter what the ABI is. ABI matter is for the API itself, and for the FFI plumbings - e.g. how to call a "C" function that takes and/or returns double/float.
The bigger problem with iOS (and other mobile devices) is that due to sandboxing, JIT is not allowed. Even then though, without JIT, luajit has a very fast interpretter (roughly x3-x4 faster than reference lua, and x2-x3 faster than other commercial lua offerings), but then FFI is somewhat slower (interpretter mode).
Re: LuaJIT maintainer's take on Apple/Clang
#8This is 6 months old on a version of XCode that is now two versions out of date. Is there a reason it's being brought up now?
No there's no reason to bring this up now. First, it has been worked around and second, VFP support for the LuaJIT ARM port is already in progress (parts are in the git repo, not enabled yet).
Re: LuaJIT maintainer's take on Apple/Clang
#9So all ARM processors that Apple uses have the real hardware floating point and LuaJit (which is a very cool engineering feat) which is supposed to speed up the execution of the Lua scripts still uses the "soft-only" calls. How much that slows down LuaJit? I guess the "soft calls" can be redirected to the pure hardware instructions? How big is the speed penalty vs. using the hardware directly?
The initial LuaJIT ARM port was targeted at low- to middle-end ARM devices without an FPU. It took some time to find another sponsor for the VFP port.
Work on VFP and hard-float EABI (armhf) is already in progress and will be available soon.
Re: LuaJIT maintainer's take on Apple/Clang
#10The LuaJIT maintainer is missing that Apple does not claim any conformance to ARM EABI. Apple's ABI is defined to be based on the AAPCS standard, but Apple makes no claims to it being exact.
In other words, it's not Linux, and it sounds like the LuaJIT maintainer is annoyed that it doesn't follow a common approach used on Linux.
Anyone that works on low-level implementations that sit below the standard platform compiler should expect this kind of thing when supporting multiple platforms.
Source: http://developer.apple.com/library/ios/#documentation/Xcode/...