Re: Question about accessing Lua tables and arrays faster

[Leo Romanoff <romixlev@...>]

----- Ursprüngliche Message -----
> Von: Coda Highland <chighland@gmail.com>
> An: Leo Romanoff <romixlev@yahoo.com>; Lua mailing list <lua-l@lists.lua.org>
> CC: 
> Gesendet: 19:31 Donnerstag, 25.Juli 2013
> Betreff: Re: Question about accessing Lua tables and arrays faster
> 
> On Thu, Jul 25, 2013 at 8:50 AM, Leo Romanoff <romixlev@yahoo.com> wrote:
>>  - But when going more and more into "native" performance domain, 
> you notice that some optimizations optimizations are missing or impossible due 
> to Lua semantics. Since LuaJIT tries to be as compliant as possible to Lua 
> specification, it cannot perform certain kind of optimizations, I guess, because 
> it would break Lua's semantics. Moreover, LuaJIT probably does not want to 
> diverge too far away from Lua, even if it could. Because it would essentially 
> result in a new incompatible language or a new incompatible set of libraries. 
> Therefore, IMHO, any changes that affect the language (data types, public 
> interfaces for C integration, public interfaces for GC integration (should they 
> exist), etc) should be agreed between Lua and LuaJIT. Any changes in these parts 
> should happen on both sides to keep Lua uniform.
> 
> LuaJIT already does this, via its FFI -- a language extension Lua
> doesn't have (unless you count the LuaFFI module, which is good for
> compatibility but not so much for speed). One typical LuaJIT
> optimization trick is to define an FFI struct with statically-typed
> fields even if you're not going to ever interface it with C code,
> because it gives you the predefined offsets and data types you were
> thinking about, which improves performance.

Yes. I know.

> Code written this way, however, doesn't work in Lua anymore.

Exactly! It doesn't work in Lua anymore, which is to be avoided whenever possible. And this was my point about the importance of alignment between Lua and LuaJIT. I was wondering if there are  certain things  that could be done/accepted/aligned on both sides (e.g. some kind of annotations, which can be ignored by Lua VM currently, but may help LuaJIT; or may be something else, which is allowed by both Lua and LuaJIT, but where only LuaJIT could currently benefit from it, and so on), so that it is a valid Lua code running on any Lua implementation, but performing particularly well under LuaJIT. It would be nice to write as little LuaJIT specific code as possible, but yet be able to benefit from LuaJIT as much as possible.

-Leo