Re: LuaJIT2 vs. vararg

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

Mark Hamburg wrote:
> Does it make sense for LuaJIT to recognize certain special cases
> for varargs in actual traces -- e.g., 0 arguments and 1
> argument? I'm thinking this would be a useful compromise for
> generic code.

The problem is not just that the number of arguments is variable.
The types of the arguments are often variable, too. But LJ2 has to
specialize to argument types early, which can easily create a
twisted maze of control-flow paths with varargs.

> For example, the following function would probably optimize well
> in practice if not in the general case:
> 
> 	function broadcast( array, msg, ... )
> 		for i = 1, #array do
> 			local obj = array[ i ]
> 			pcall( obj[ msg ], obj, ... )
> 		end
> 	end

The fixargs of a vararg function are treated separately. 'array'
and 'msg' would compile just as usual.

The trouble comes with the implicit, late dispatch via obj[msg].
This prevents hoisting of the specialization to the receiver. If
you usually pass arrays of homgeneous object types, you could
fetch the receiver outside the loop. It's not feasible for the
compiler to infer this.

Assuming the message receiver is a fixarg function, the varargs
would be specialized to their number and type before the call.
That's the easier part of vararg handling.

The more difficult part is iterating over varargs, because then
they need to be treated more like an array. Type-variance will
again kill performance.

--Mike