lua-users home
lua-l archive

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

Olivier Hamel wrote:
KHMan wrote:
Olivier Hamel wrote:
David Manura wrote:
On Fri, May 15, 2009 at 11:25 AM, Philippe Lhoste wrote:
On 15/05/2009 14:14, Olivier Hamel wrote:
Metalua resorts instead to writing its own bytecode generator.

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.

Not 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?

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.

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?

Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia