lua-users home
lua-l archive

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

Pavel Antokolsky aka Zigmar wrote:

Hello all!
As I see from the source, current Lua off-line compiler (luac) uses
internal lua compiler to generate code for Lua VM. And internal
compiler, as stated, is trade-off between compilation speed and level
of optimisations, which is good for run-time compiler, but not the
case for off-line one. The off-line compiler does not have to take
into account compilation speed (well, almost, comparing to run-time
system), so maybe it worth creating different compiler for off-line
compilations, that will produce more efficient code than it's run-time

The main questions:
1) How much it is possible to optimize bytecode if not to take
compilation time into consideration (compared to current run-time
2) If gain from 1 of large enough, what is the effort required to
create and maintain additional compiler and if it worth it?
3) What are possible pitfalls in such approach?

I'm going to follow Luiz's opinion on this as well. I'd have to question the benefit of doing so. Lua code isn't something I'd consider to be that amenable to optimisations (at least in a similar fashion to how a language like C is).

This is mostly because of the dynamic-typedness. You can pull the whole environment from under another lua script that you call, etc. I reckon that leaves very few places to apply to global optimisations to -- you don't really know the state of anything at compile-time... And in a worse case than C++, sub-expression-elimination would become very difficult considering you don't know if the two things you're adding right now are integers, tables (with metatables), etc. That makes it very difficult to decide whether a particular operator is commutative in a particular circumstance, etc.

Has anyone done a profile of a "typical" luac called program? My rather uneducated guess would be that the hashing into the tables would have an impact coming close to the execution of the byte-code itself. If this /is/ the case you wouldn't gain that much by just changing bytecode to native code...

Peephole-optimisation might be a goer -- I assume there would be some level of redundancy in the generated byte-code. But this is really something that could be applied to the lua.lib portion anyway I'd assume -- but considering it was stripped from lua5 because it was becoming to difficult to maintain?

In any case, I think there are already tools that are specifically created for these purposes. C is there if you want some more speed out of your inner-loops :)

Of course, if you want to give it a go, give it a go - I'd be interested in the implementation myself (from an intellectual-curiosity stand-point ;)...

- Mab