Hacker News Reader

Comment by mikemike | Hacker News Reader

LuaJIT/ARM runs fine on an Cortex-A8 or Cortex-A9. The instruction scheduling for the simpler in-order architectures is beneficial for the newer architectures or for out-of-order architectures, too.

And even though it needs at minimum ARMv5, it does take advantage of some ARMv6 and ARMv7 instructions, if available. But this has a rather small impact on the performance.

The only real issue is that this is a soft-float port for now. So it doesn't take advantage of VFP, even if the CPU has it. I'll add hardware floating-point support, when/if I get a follow-up sponsorship for this.

View on HN

What kind of $ range makes it worth your time? I work at a mobile game studio that makes heavy use of lua and I could see us putting some money into it.

Also, does LuaJIT differ any from the stock lua interpreter when it comes to GC performance? It's a continual source of pain for us to have to manually tweak GC parameters on a per-app basis depending upon how heavily lua is used.

Well, I don't have an estimate of the costs for this feature, yet. And I need to talk with the current sponsor of the ARM port first.

Yes, LuaJIT uses its own memory allocator, which improves performance for workloads with lots of allocations. And LuaJIT's memory footprint for most object types is lower, too.

However LuaJIT 2.0 still has more or less the same GC engine as Lua 5.1. LuaJIT 2.1 will feature a new garbage collector, see the LuaJIT roadmap 2011: http://lua-users.org/lists/lua-l/2011-01/msg01238.html

In the meantime, your best bet is to avoid temporary allocations or to use manual memory management with the LuaJIT FFI, see: http://luajit.org/ext_ffi.html

LuaJIT is a drop-in replacement for Lua. Try it with your apps and report back if you encounter any problems. You need to use git HEAD to get the JIT compiler for ARM (disabled for iOS -- don't complain to me).

Glad to hear its a minimum of an ARMv5 - I have a project where I have been using plain Lua on an ARM926EJ-S which could use a performance boost.

How much of a difference does instruction scheduling vs no instruction scheduling make approximately? How about for out-of-order architectures?

Sorry, I have no quantitative comparison for that. It's baked into the design of the register allocator to schedule loads early and to rematerialize constants far ahead of their use. And I'm contemplating to add an extra scheduling pass for some cases that are currently not covered well.

From experience in tuning the interpreter, instruction scheduling (esp. load scheduling) can easily make a 20-50% difference on some tight loops for a simple in-order architecture. This is much less of an issue with an out-of-order architecture, of course. It's still beneficial to do instruction scheduling for all ARM architectures, because there's apparently a huge performance difference compared to the out-of-order engines on contemporary x86/x64 CPUs.

Reply on news.ycombinator.com