Re: Question about accessing Lua tables and arrays faster

[Leo Romanoff <romixlev@...>]

>________________________________
> Von: Tim Hill <drtimhill@gmail.com>
>An: Leo Romanoff <romixlev@yahoo.com>; Lua mailing list <lua-l@lists.lua.org> 
>Gesendet: 17:14 Donnerstag, 25.Juli 2013
>Betreff: Re: Question about accessing Lua tables and arrays faster 
> 
>
>
>
>
>On Jul 25, 2013, at 8:00 AM, Leo Romanoff <romixlev@yahoo.com> wrote:
>
>
>>Rationale:
>>- Many static languages with a type system allow for definition of structural types (e.g. structs in C, classes in Java, etc). Access to the fields of such types is usually very cheap in those languages. If one maps such structural types to Lua tables (and this is the most obvious solution, I guess), then sematically everything is fine. But now every access to a field results in a table lookup, which introduces some overhead. It would be nice to have a faster way of accessing fields of tables.
>>
>>- Many high-performance applications work intensively with arrays. Currently, Lua uses the same datatype, namely tables, for both arrays and maps. Accessing arrays from Lua is not extremely fast currently. (Lua interpreter does not use even those lua_rawseti/lua_rawgeti functions, IIRC. Only C libs for Lua can do it). It would be nice to have a faster way of operating on arrays in Lua.
>>
>>BTW, I did some experiments where I create an array of 1000000 elements and then perform a 1000 iterations over it, touching each element and assigning a new value to it or incrementing its current value. I implemented the same algorithm in pure Lua, as a C library for Lua which uses lua_rawseti/lua_rawgeti, and as a C program. The outcome is that pure Lua solution is the slowest, the C library for Lua is roughly 1.5 times faster and C version is about 14.5 times faster than pure Lua solution. 
>>
>
>I think this is rather missing the point of Lua. As a scripting language, Lua has a different balance between performance and convenience than languages such as C. Pretty much anything you do in C will be faster than Lua (but will need many more lines of code), and if you need the performance of C, well, er .. then do it in C!
>
>
>Things like duck typing, garbage collection, and generic tables are (mostly) aimed at denser code where the runtime does more work on behalf of the developer, and this extra work will slow the program somewhat. To my mind the beauty of Lua is that these features make the development of complex logic far far easier than in languages that focus on raw compiled execution speed, with a rather minimal loss in performance.
>

Yes, I agree with you on most points. I know very well that typically scripting langauges aim for things you mention and not primarily for ultimate peformance. This is a typical tradeoff. But see my comments below.

>No-one is going to write a production video codec in Lua, it's just not designed for that. However, they MIGHT wrap such a codec (written in C) into a library that can be called from Lua, thus letting C do the heavy lifting but Lua make all the business decisions around the use of the codec.
>
>
>Have you looked at LuaJIT?


Of course I have looked at it. I like Lua as a langauge and Lua VM as its implementation, but LuaJIT is a real gem!!! IMHO, Lua with LuaJIT is very competitive even with native apps compiled from C/C++. To some extent this is a reason why I ask many of my questions.  Let me explain:

- Without LuaJIT, Lua is a nice, small, very elegant and rather efficient scripting language with a very good C integration. But it is not so exceptionally spectacular compared to other scripting languages. After all, many of them can do roughly the same, but may be not so elegantly. Some of those languages are slower, more heavy-weight, some do not have such a good integration with C. But most would have tables, functions, closures, duck typing, garbage collection, etc.

- Now, Lua with LuaJIT can be a game changer! Its performance is exceptional!!! It beats almost any other scripting language and sometimes even natively compiled progams and JVMs due to its tracing JIT technology and all that while preserving all the advantages of Lua that we all know and which you mentioned above.  Since it has such a good performance, it is very tempting to start thinking how to extend the reach of Lua+LuaJIT beyond a typical domain of scripting languages. One can start thinking of putting more of the overall code and business logic in Lua+LuaJIT. You can express your logic much easier, you have more freedom and you don't loose your performance. It is a win/win situation. LuaJIT is the "unique selling point", but if you "buy" LuaJIT, you also "buy" Lua. So, this is good for the language as it increases its adoption.

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

My questions and views on LuaJIT just scratch the surface, I guess. I would be interested to hear an opinion from Mike Pall on this. Are there any features in Lua which make it harder for LuaJIT to get the best performance? Are there any missing features that would allow LuaJIT to become even more efficient?  If there are such things, it would be interesting to hear about them. In particular, if there are some required extensions to Lua that do not hurt Lua/LuaVM, but would make LuaJIT much more efficient, I'd really consider adding them to Lua.  

Somehow, this discussion reminds me of Javascript/asm.js and similar experiements. Turning things the otherway around. Compiling native apps to dynamic languages or their subsets and yet running them with almost native speed. Running dynamic languages with almost native speed. Why not?

-Leo