 |
lua-l archive |
|
|
||
|
Mike Pall wrote:
[snip] The main reason is that LuaJIT still uses the Lua frame and stack structures. This makes it easy to switch between interpreted and compiled code. And most of the debug support can be reused, too. Reducing the function call overhead any further is hard without major conceptual changes. Inlining short Lua functions may be easier (and is potentially faster).What do you think the performance limits are for just-in-time compilation in Lua?[snip]
I think up to a certain point, there is only so much one can do to speed things up without sacrificing something. If a JIT is to function exactly like interpreted Lua, one cannot exactly produce very fast code approaching the speed of C or bare metal code.
It's a tradeoff -- for top speed, we'd have to start cutting some functionality off. What would achieve top speed? We'd need a lite-Lua profile that is largely procedural and where most data types can be made static. Things like metamethod checking will need to be dropped unless it is explicitly needed. There cannot be strict semantics; integers must be used where appropriate so that one can forget about conversion.
Where applications are concerned however, a lite-Lua profile would not be appropriate where one wants to JIT the entire Lua source code, but it would greatly accelerate a subset of functions. So it assumes the application is mostly fast enough on interpreted Lua, but there are a few processing intensive functions that badly need accelerating.
-- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia