|
»
« Return to Thread: ANN: LuaJIT 1.1.0
Re: ANN: LuaJIT 1.1.0
by Kein-Hong Man
::
Rate this Message:
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
> [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
« Return to Thread: ANN: LuaJIT 1.1.0
| Free embeddable forum powered by Nabble | Forum Help |
