 |
lua-l archive |
|
|
||
|
Olivier Hamel wrote:
KHMan wrote:If for some reason you change the bytecode order, or add new bytecodes, compiled scripts will ONLY execute on a VM with the matching Op Codes/Op Codes order. It's a well known thing, but if it's supposed to be a portable optimizer then it would probably be best to have it output it's optimized code in Lua source, not Lua bytecode/opcodes.Olivier Hamel wrote:David Manura wrote:I stand corrected. :) Thanks for the info, I'd've thought it be the other way around really. I'm not too sure having it emit bytecode is a good idea since it breaks the second you move the byte code around.On Fri, May 15, 2009 at 11:25 AM, Philippe Lhoste wrote:On 15/05/2009 14:14, Olivier Hamel wrote:[snip] Metalua resorts instead to writing its own bytecode generator. [1] http://lua-users.org/wiki/OptimisationCodingTips [2] http://en.wikipedia.org/wiki/Strength_reduction [3] http://gcc.gnu.org/onlinedocs/cpp/Line-Control.htmlNot all optimizations can be done using source-to-source translation. We might want to bypass the Lua locals allocator, for example. Good or bad (or complications galore) I dunno, but it's a cute academic exercise. Still, a user might want the result in source form, so I think there is a place for either kinds of output.When I read this: "since it breaks the second you move the byte code around." It's so vague, what does it mean anyway, exactly?
True, but if there are optimizations I want to do that need to be done in bytecode, I'd output to bytecode in a second.
Still, it's pretty much more of an academic project sort of exercise, I've looked at a whole range of possible optimizations and I don't see any big wins that would prompt me to work on such an optimization project. (I'd go for LuaJIT if I needed performance.)
But I'm curious, for example, in function inlining, how much of a performance boost can we get for inlining non-tiny-sized functions? Anyone has some numbers to share?
-- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia