Re: LuaJIT2 vs. vararg

[Mark Hamburg <mark@...>]

Here were the opportunities I saw for optimization in my broadcast routine:

1. The dynamic dispatch is over all a killer for cross-routine optimization, but can parts of the method lookup be hoisted based on the fact that the key isn't changing within the loop? We still have to do the method lookup per object, but I would think that parts of it might be amenable to moving outside the loop.

2. Are there optimizations available for passing varargs of particular lengths to the next level -- particularly in the 0 and 1 cases? Beyond that I would expect a simple loop copying the values from stack frame to stack frame to probably win, but I could imagine some opportunities with respect to the probably not uncommon cases where the varargs list is short or empty.

3. The array iteration itself is an obvious opportunity for some optimization, though would it be better to write it as an ipairs call?

4. If we keep broadcasting the same message, are there opportunities to optimize based on that? That risks explosive growth if we don't routinely use the same message, so are there ways that the code could be structured to indicate that specialization based on message is likely to be useful? In particular, consider the case where we are sending a particular message with 0 or 1 arguments and most objects will have the same implementation for that message. Can a tracing JIT pick this up? Are there ways to help it pick it up? For example, if I've got a recompute graph, I might want to do something like:

	broadcast( self.dependents, "markDirty" )

markDirty may be dynamic to allow for overrides, but most of the time it will probably execute fairly standard behavior. It would presumably be good to have this result in optimized code for the common case.

Mark

-----

function broadcast( array, msg, ... )
	for i = 1, #array do
		local obj = array[ i ]
		pcall( obj[ msg ], obj, ... )
	end
end