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>
> CC: Lua mailing list <lua-l@lists.lua.org>
> Gesendet: 22:13 Donnerstag, 25.Juli 2013
> Betreff: Re: Question about accessing Lua tables and arrays faster
> 
> On Thu, Jul 25, 2013 at 11:31 AM, Leo Romanoff <romixlev@yahoo.com> wrote:
>>  Exactly! It doesn't work in Lua anymore, which is to be avoided 
> whenever possible.
> 
> And this is where we disagree. Why should it be avoided?
> 
> The languages have already diverged. LuaJIT and Lua 5.2 have both
> added features that weren't in their common ancestor, Lua 5.1. 

IMHO, current differences seem to be pretty small.

> It's
> certainly possible (in fact, not even difficult) to write code that
> supports all three targets; most Lua 5.1 code will run unmodified on
> both LuaJIT and Lua 5.2.
> 
> However, if you're to the point where you're looking for ways to go
> past the implementation details of the VM for performance reasons,
> you've already given up on compatibility. Supposing the code were to
> FUNCTION on Lua 5.2 (for example, if you're not using setfenv and you
> don't depend on nil/NULL equivalence and you're okay with loading
> LuaFFI), the performance characteristics would differ.

If you mean that they would be anyway incompatible in terms of performance, I agree.
But I had more a source code compatibility in mind. 
Having a similar performance would be even better, but it's not realistic without significant Lua VM improvements or making LuaJIT much slower :-)

> There's nothing here that says that incompatibility is avoided
> whenever possible. Keeping the language CORE compatible is valuable,
> but there's nothing practical about taking a dogmatic approach to
> avoiding extensions.


It is not about being dogmatic. It is more about avoiding being implementation specific where it could be done in a compatible way.
Take asm.js as an example. It is a subset of JavaScript. It still runs on ANY JavaScript implementation. But some implementations recognize the hints provided in asm.js based source code and execute it very efficiently. 

May be something similar in spirit could be done for Lua? E.g. some sort of optional annotations (as special comments? or special elements in metatables?) indicating types or some other hints, like "the structure of this table will never change", "this variable or this object is read-only", etc. Such indicators/hints would be purely optional and can be ignored by Lua implementations, but they can be also taken into account and used for optimizations, if a given Lua implementation supports it.

But of course, if nothing else works, you start using implementation specific extensions like LuaFFI and so on. 

-Leo