Hacker News Reader

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?

View on HN

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.

Hard-float has worked for quite some time.

All that's happened recently is that the Debian name for it "gnueabihf" is recognized.

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

Reply on news.ycombinator.com