lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



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.

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?

--Tim