Re: LuaJIT2 vs. vararg

[Mark Hamburg <mark@...>]

On Nov 25, 2009, at 4:07 AM, Mike Pall wrote:

> 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.

I would presume that the message send would optimize as well as any message send -- though it's more unique because the message is "unique" to the call. Would one be better off using code generation to build something fitting the obj:msg( ... ) pattern?

I was also figuring that even without type information, there ought to be a win in knowing how many arguments will be passed to each call -- though here again code generation could also be used if need be.

It just seems like the JIT logic should allow one to avoid building custom functions via string manipulation and loadstring. Or am I expecting too much of a tracing JIT?

Mark