 |
lua-l archive |
|
|
||
|
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 counterpart. 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 compiler)? 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