[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: ANN: LuaJIT 1.1.0
- From: Kein-Hong Man <mkh@...>
- Date: Wed, 15 Mar 2006 12:53:33 +0800
Mike Pall wrote:
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?
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
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia