lua-users home
lua-l archive

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

Sorry for the late reply and thank you for the prompt one!

On 21/09/2011 10.38, KHMan wrote:

Why don't you take it up? It seems to be a popular doc. I'll help out
and you put your name first. :-) :-)

Alas, although it's a tempting offer :-) I must decline. (Very kind of you, anyway!) I've got very little free time and sadly I don't work as a developer any longer, so Lua is just an hobby for me and a way to keep my programming skills in good shape. I already do some basic beta testing for Steve Donovan's LDoc (with a very lax schedule from my side - given my time constraints) and that already saturated my "serious commitment bandwidth".

I'm not really an "assembler geek" (most serious assembly stuff is high over my head), but VM listings brings up some "ancient memories" to my mind: ~20 yrs ago I did some x86 asm programming at the university, but the real fun was programming a glorious Apple //e in machine language (sic - using handmade lookup tables and pencil and paper memory layouts - ahh! the pleasures of early youth :-) and debugging it using the miniassembler and the monitor program (call -151 anyone ?!? :-). Well the 6502 processor was so simple it was really fun, after all :-D


Better to look at the opcodes, then lvm, and trace calls to other files
from there.

Thanks for the pointer!

On a related note, out of curiosity I wonder if there is something
like an "assembler" targeting Lua VM. I know Lua VM specification
is a Lua implementation detail, but I'm curious to know if someone
has tried this way to enhance the performance of Lua in
time-critical code (assuming that hand-crafted Lua bytecode could
squeeze some cycles out of the VM).

and also something by Zed Shaw in the past, IIRC.

I don't think writing out bytecode assembly-style will give big
performance wins. It's still interpreting... Mike Pall's Lua interpreter
is already a lot faster, let alone the JIT.
Yes indeed! I never used it (I don't have the need for *that much* speed), but I'm always amazed by the reports about the performance of LuaJIT. The fact that it could beat pure C code in some cases is something unreal (at least for an uninitiated in compiler design like me)! I think I read somewhere (IIRC) it is deemed probably the most performing JIT compiler for a (dynamic?) language ever!

Most things that people have
thought of will probably need modification of Lua source code (for
example, a recent thread about reducing lookups).

Maybe you want to try adding some super-instructions and see if there is
a significant performance change -- what I would be real interested in
right now is instruction traces and stats to show which bytecode pair
(or chain) is most frequent...

That said, I try to code a reasonable algorithm and that's it. Silicon
is too cheap and it has wiped out most extreme optimization practices.
All the same, as academic exercises, it's an interesting area.

Thanks for all the insight and for satisfying my curiosity!

-- Lorenzo