5 ms·

LuaJIT maintainer's take on Apple/Clang

86 points by zachwill 14y ago

FigBug 14y ago
This 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?
- mikemike 14y ago
  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).
  - schwa 14y ago
    What is the work-around? I'm trying to get luajit working on iOS 6+ on ARMv7 and above...
- bonch 14y ago
  Is there a reason it's being brought up now? Flamebait.
anonymoushn 14y ago
You can browse this with dates and with 7 less ads per page here: http://lua-users.org/lists/lua-l/2012-02/msg00597.html http://lua-users.org/lists/lua-l/2012-02/msg00597.html
protomyth 14y ago
am 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.
losethos 14y ago
Fixed-point integer math is faster than floating, but not by much anymore.
acqq 14y ago
So 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?
- malkia 14y ago
  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).
- mikemike 14y ago
  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.
  - ohmantics 14y ago
    Hard-float has worked for quite some time. All that's happened recently is that the Debian name for it "gnueabihf" is recognized.
flatline3 14y ago
The 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/Conceptual/iPhoneOSABIReference/Introduction/Introduction.html#//apple_ref/doc/uid/TP40009020-SW1 http://developer.apple.com/library/ios/#documentation/Xcode/...
- mikemike 14y ago
  This is not about Linux. Every brittle OS on ARM uses the standard ABIs. But Apple can't? Gimme a break.
  - deleted 14y ago
    [deleted]
  - ohmantics 14y ago
    Apple's ABI for iOS is a custom derivative of APCS, not AAPCS. They do not even try to conform to the AAPCS ABI, nor should they need to. iOS has a soft-float ABI, but uses the float glue names from libgcc, not the EABI names. This whole thing reads like the LuaJIT guy whining that he has to do some work to port to iOS. The compiler-rt library provides these functions and it shouldn't take him more than 10 minutes to figure out the proper names to use on iOS.
    - mambodog 14y ago
      Just so you know, it's the "LuaJIT guy" that you're replying to there.
      - acqq 14y ago
        That doesn't mean that ohmantics here doesn't have a good point (that it's not realistic to assume that porting to the different platforms doesn't involve some work specific to the platform) and gives the precise information where the soft-float functions on iOS can be found. I can also understand Mike too that he didn't want to spend the time on that port (I think, because iOS doesn't allow apps any Jiting, thereby limiting the power of LuaJit on iOS). Still the information that ohmantics gives regarding compiler-rt library can help us obtain a balanced view.
shasty 14y ago
who gives a shit
pygy_ 14y ago
FWIW, Mike Pall (mikemike 'round these parts) is much more than the maintainer of LuaJIT. He's the sole author of the project, which is being actively developed.
gregholmberg 14y ago
Apple is actively trying to fix this problem. If you know any talented compiler gurus who want to work at Apple, you could refer them. [0][1] . [0] "LLVM Backend Compiler Engineer" http://jobs.apple.com/index.ajs?BID=1&method=mExternal.showJob&RID=113414&CurrentPage=1 http://jobs.apple.com/index.ajs?BID=1&method=mExternal.s... [1] "LLVM Backend Compiler Engineer" http://jobs.apple.com/index.ajs?BID=1&method=mExternal.showJob&RID=118224&CurrentPage=1 http://jobs.apple.com/index.ajs?BID=1&method=mExternal.s...
- drats 14y ago
  I would recommend people don't work for Apple. It's one thing to lie about computing history and say you invented everything so that customers believe it and give you lots of money (which you then use to outsource jobs and stop the company charity program) it's another thing entirely to drink your own kool-aid and start a series of the most embarrassing lawsuits I've ever seen. Apple is now officially not just a dodgy liar, but they are a joke. Work there at your own peril, I personally think they are a complete disgrace.
  - bonch 14y ago
    You're not telling hard truths. You're just embarrassing.
  - krickle 14y ago
    I think regardless of the lies, they had a superior operating system up until Lion. Now their business practices and complete disregard for their developers' comfort is fairly inexcusable. Nor do I like the draconian systems of the App Stores.
  - tom125 14y ago
    Well, Apple's stock has increased massively over the past few days of the trial between Apple and Samsung, so the shareholder's can't think it's "embarrassing". Looking at the share price, I'd have thought the shareholders think its going quite well, especially when you think that they didn't have an especially good quarter.
chj 14y ago
From what I know without jailbreak iOS doesn't support JIT at all.

86 points by zachwill 14y ago

This 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?

mikemike 14y ago
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).
- schwa 14y ago
  What is the work-around? I'm trying to get luajit working on iOS 6+ on ARMv7 and above...
bonch 14y ago
Is there a reason it's being brought up now? Flamebait.

anonymoushn 14y ago

You can browse this with dates and with 7 less ads per page here: http://lua-users.org/lists/lua-l/2012-02/msg00597.html http://lua-users.org/lists/lua-l/2012-02/msg00597.html

protomyth 14y ago

am 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.

losethos 14y ago

Fixed-point integer math is faster than floating, but not by much anymore.

acqq 14y ago

So 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?

malkia 14y ago
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).
mikemike 14y ago
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.
- ohmantics 14y ago
  Hard-float has worked for quite some time. All that's happened recently is that the Debian name for it "gnueabihf" is recognized.

flatline3 14y ago

The 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/Conceptual/iPhoneOSABIReference/Introduction/Introduction.html#//apple_ref/doc/uid/TP40009020-SW1 http://developer.apple.com/library/ios/#documentation/Xcode/...

mikemike 14y ago
This is not about Linux. Every brittle OS on ARM uses the standard ABIs. But Apple can't? Gimme a break.
- deleted 14y ago
  [deleted]
- ohmantics 14y ago
  Apple's ABI for iOS is a custom derivative of APCS, not AAPCS. They do not even try to conform to the AAPCS ABI, nor should they need to. iOS has a soft-float ABI, but uses the float glue names from libgcc, not the EABI names. This whole thing reads like the LuaJIT guy whining that he has to do some work to port to iOS. The compiler-rt library provides these functions and it shouldn't take him more than 10 minutes to figure out the proper names to use on iOS.
  - mambodog 14y ago
    Just so you know, it's the "LuaJIT guy" that you're replying to there.
    - acqq 14y ago
      That doesn't mean that ohmantics here doesn't have a good point (that it's not realistic to assume that porting to the different platforms doesn't involve some work specific to the platform) and gives the precise information where the soft-float functions on iOS can be found. I can also understand Mike too that he didn't want to spend the time on that port (I think, because iOS doesn't allow apps any Jiting, thereby limiting the power of LuaJit on iOS). Still the information that ohmantics gives regarding compiler-rt library can help us obtain a balanced view.

shasty 14y ago

who gives a shit

pygy_ 14y ago

FWIW, Mike Pall (mikemike 'round these parts) is much more than the maintainer of LuaJIT. He's the sole author of the project, which is being actively developed.

gregholmberg 14y ago

Apple is actively trying to fix this problem. If you know any talented compiler gurus who want to work at Apple, you could refer them. [0][1] . [0] "LLVM Backend Compiler Engineer" http://jobs.apple.com/index.ajs?BID=1&method=mExternal.showJob&RID=113414&CurrentPage=1 http://jobs.apple.com/index.ajs?BID=1&method=mExternal.s... [1] "LLVM Backend Compiler Engineer" http://jobs.apple.com/index.ajs?BID=1&method=mExternal.showJob&RID=118224&CurrentPage=1 http://jobs.apple.com/index.ajs?BID=1&method=mExternal.s...

drats 14y ago
I would recommend people don't work for Apple. It's one thing to lie about computing history and say you invented everything so that customers believe it and give you lots of money (which you then use to outsource jobs and stop the company charity program) it's another thing entirely to drink your own kool-aid and start a series of the most embarrassing lawsuits I've ever seen. Apple is now officially not just a dodgy liar, but they are a joke. Work there at your own peril, I personally think they are a complete disgrace.
- bonch 14y ago
  You're not telling hard truths. You're just embarrassing.
- krickle 14y ago
  I think regardless of the lies, they had a superior operating system up until Lion. Now their business practices and complete disregard for their developers' comfort is fairly inexcusable. Nor do I like the draconian systems of the App Stores.
- tom125 14y ago
  Well, Apple's stock has increased massively over the past few days of the trial between Apple and Samsung, so the shareholder's can't think it's "embarrassing". Looking at the share price, I'd have thought the shareholders think its going quite well, especially when you think that they didn't have an especially good quarter.

chj 14y ago

From what I know without jailbreak iOS doesn't support JIT at all.