Re: LuaJIT2 vs. vararg

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

Alexander Gladysh wrote:
> I've got an impression that LJ2 b2 does not optimize functions with varargs.

Yes, that's mentioned on the status page.

> I'm running this silly benchmark:
> http://github.com/agladysh/luamarca/blob/master/bench/arguments.lua
> 
> luajit2
> -------------------------------------------------------------------
>                 name |     rel | abs s / iter = us (1e-6 s) / iter
> -------------------------------------------------------------------
>      assert_is_alloc |     nan |   0.00 /   10000000 = 0.000000 us
>         plain_assert |     nan |   0.00 /   10000000 = 0.000000 us
>            assert_is |     inf |   0.01 /   10000000 = 0.001000 us

The assertions in these cases can be hoisted, so they take up no
time in an inner loop. That's exactly what you want.

>   args_select_simple |     inf |   3.23 /   10000000 = 0.323000 us
>  args_recursive_simp |     inf |   3.26 /   10000000 = 0.326000 us
>    args_recursive_ln |     inf |   3.63 /   10000000 = 0.363000 us

None of these are compiled right now (see above). And even when
this is added, I'm pretty sure performance would still be rather
low. I'm not sure that all of these checks will be hoistable and
I cannot recommend this approach in general.

> It seems that in LT 1 recursion is the fastest way to walk through varargs.
> In LJ2 it is the slowest way. Would it always be like this or is it just
> some beta version artifact?

All of them will be slower than direct checks and recursion would
probably be the slowest.

> I want to write fastest possible arguments() function for LJ2.

Maybe you need to change your goal instead. Either use source-code
transformation and inline the checks, e.g. turn function(a:number)
into function(a) + assert_is_number(a, 1). Or just drop the explicit
type checks -- that's very un-Lua-ish, anyway. You'll get an error
on the first use instead. A test suite will catch it either way.

> But, perhaps, something is known at this point. I use vararg a lot when I
> write generic code, so I want, from the beginning, to write it in the way
> LJ2 would like it.

You may want to reconsider this decision. Vararg processing *is*
expensive and I can't do much about it. Now that everything else
has gotten so fast with LJ2, this will be even more noticeable.

--Mike