Re: LuaJIT2 performance for number crunching

[Javier Guerra Giraldez <javier@...>]

On Mon, Feb 14, 2011 at 4:41 AM, steve donovan
<steve.j.donovan@gmail.com> wrote:
> we have been spoiled by optimizing compilers for the
> last 20 years, and so the advice about hand-optimization has basically
> been "leave it to the compiler".  But LuaJIT is still young, and there
> are things that need to be explicitly handled.

i think it's not because youth/maturity; but being Lua such high level
language, the difference between what's optimized and what's not
becomes huge.

In lower level languages, compiler optimizations free the programmers
from menial things, like creating lots of intermediate variables, or
inlining functions and then optimizing them in context.  good things,
but only in extreme cases reach 30-40% performance improvements.  the
biggest difference these days comes from cache-friendly structures, an
area where compilers can do very little.

LuaJIT, OTOH, can optimize away lots of the nice things that make Lua
nice and not so fast (when compared with C), like float/integer
casting, struct/like table accesses, and other amazing things.
Together, all this things get easily the 10-15x impact, but when it's
not possible, the miss is painfully noticeable.

in short, when in C you don't play nicely with the optimizer, you
don't lose much; but in Lua, losing 'Mike magic' can break a project.

-- 
Javier