[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaJIT 2 ffi (casting / force hotpath)
- From: Quae Quack <quae@...>
- Date: Sat, 15 Jan 2011 20:11:04 +0000
On 15 January 2011 19:11, Mike Pall <email@example.com> wrote:
> ... and want to copy two components, then do it like this:
> for i=0,99 do s.x[i] = s.y[i] end -- Good!
> ... and NOT like this:
> local x, y = s.x, s.y -- Creates two intermediate references.
> for i=0,99 do x[i] = y[i] end -- Works, but please don't!
> In LuaJIT's case, intermediate references are always created in
> the interpreter, but the JIT compiler can easily eliminate them if
> they are consumed right away. This doesn't work if you store them
> in some local variable and this variable escapes to some side
> exit. Then it gets really difficult or impossible to eliminate the
> allocation of the intermediate reference (and allocation sinking
> is not yet implemented, too).
> A C compiler easily gets into trouble with pointer aliasing and
> needs some expensive analysis to turn this back into the original
> index expression the programmer tried to 'optimize'. :-)
> Morale: what a programmer may think is helpful for the compiler,
> often is not. So write things in the most straightforward way.
This seems so strange to me; In the regular lua interpreter we
obviously gain (by removing 2 hash lookups in your example)
additionally, i DO find the latter example much more straight forward.
==> in more complex expressions you end up typing 's' many more times,
which I would find ugly.
What sort of performace do we loose by continuing this practice?