Re: LuaJIT2 performance for number crunching

[T T <t34www@...>]

On 17 February 2011 10:33, Mike Pall <mikelu-1102@mike.de> wrote:
> T T wrote:
>> [...] and added a big loop at the end, so it runs for a bit.
>
> You're passing a new closure every time -- don't do that. The
> compiler specializes to each one of them and bad things happen.
>
> Write that stuff as:
>
>  local function f(x,y)
>    return x+y
>  end
>
>  for i=1,1e5 do
>    ode_dormandprince(f, 0, 1, 1.24, 1e-5, 1, 0.01, 1000)
>  end
>  print(ode_dormandprince (f, 0, 1, 1.24, 1e-5, 1, 0.01, 1000))
>
> This improves the runtime by an order of magnitude!
>
> Also, the variant with the inline constants is 10% faster and the
> generated machine code is about 40% less (2.8K vs. 4.6K on x64).
> The effects on performance are less pronounced with FP constants
> than with integer constants. I think this matches my prediction
> quite well.

Thanks.  So you were right ;) it will run faster.  But a meager 10%
difference is not something I would loose my sleep over.  In short:
constants in Lua won't improve things much.  Case closed.

>
>> Is code
>> templating/specialization/manual unrolling the only way to address
>> that in luajit?  Wouldn't it be possible to do something like in the
>> example I posted earlier?
>
> There are three different issues:
>
> 1. Actual constness of variables that is undetected: needs
>   global bytecode analysis. Tricky.
>
> 2. Specializing to the actual value of a variable (pseudo-const):
>   needs manually inserted directives; variable may lose this
>   property if stored/reloaded.
>
> 3. Different loop unrolling heuristics: probably needs manually
>   inserted directives, too.
>
> Not that simple -- send a patch. :-)

I wish I had your brain and could join in with patches.  I can only
hope that you (or someone equally qualified) will come up with some
clever solution to this.

Cheers,

Tomek