Re: LuaJIT2 performance for number crunching

[Mike Pall <mikelu-1102@...>]

Francesco Abbate wrote:
> The problem here is
> that LuaJIT2 will only optimize the innermost loops and do almost
> nothing to optimize the code in the outer loop.

This is wrong. It anchors code at loops, but it compiles and
optimizes _all_ kinds of hot code paths.

The region selection heuristics fail for the specific example
because of the sheer mass of way-too-short loops.

> > In Lua we can do the same: specialize the Lua code at runtime for
> > the number of dimensions, memoize the code in a table and dispatch
> > based on the dimension. I.e. string.format + loadstring +
> > memoization table.
> 
> Yes, you can do that and this is an interesting possibility but it
> does also increase significantly the level of complexity. You cannot
> just implement your algorithm but you have to generate at run-time the
> code for your routine in a way that LuaJIT can optimize. This can be
> done in same cases but I think that it cannot be proposed as a generic
> method to implement algorithms.

I beg to differ. It's a common idiom in Lua to generate code at
runtime. And it's quite easy, too.

If someone tells you to use templates for C++ because that will
make your code an order of magnitude faster -- do you tell him
that you're too lazy to implement that or would you rather take
that order of magnitude speedup?

> Well, this is what I've done but it was not working!!! :-)

Because you didn't try hard enough. Naive translations of programs
written in other languages almost never perform well. An idiomatic
rewrite in Lua would look quite different. It could also take
advantage of multiple-return values and other features the
language has to offer.

I showed you how to make it even faster than the C version. It's
your decision, whether you'll heed that advice or not.

> ...so you should say: rewriting mixed C/Lua code in pure Lua (+FFI)
> and program everything in procedural way using only a single big loop
> to be sure that LuaJIT optimize it :-)

This is wrong advice in general, as I've explained above.

It does help if your inner loops with non-constant bounds iterate
more than two times, but that's a general wisdom which applies to
any language.

> In my point of view the potential of the LuaJIT compiler will be much
> greater for numerical algorithms and also non-numerical ones when it
> will be able to optimize at least two ot three levels of nested loops.

Your assumptions are wrong, so your conclusion is wrong. LuaJIT is
quite competitive on SciMark, which basically consists solely of
nested loops.

--Mike