Re: Lua Virtual machine

["John Passaniti" <jmp@...>]

> but I read, that someone had rebuilt the Virtual machine in x86
> assembler with the result, that it performs two time as fast as
> before. I had a look at the c source of Lua and thought about,
> if it would be possible to do such thing for Lua too.

It's possible, but the standard method of speeding up code is to profile it
to find the routines that take up the most amount of time.  I haven't done
this yet for Lua, but I suspect that the total time spent in the virtual
machine isn't all that great-- as a percentage of the total execution time.

That's especially true depending on how one extends Lua.  Where I work,
another person is adding features to a Lua program I wrote.  But since he
doesn't really understand my code and since they don't really understand
Lua, they have added their code as C code and wrote minimal Lua wrappers
around that.  That's not the way I would do it, but when deadlines come
down, sometimes the less elegant path is chosen.

My point here is that in my particular case, even if the virtual machine
was infinitely fast, it wouldn't make the code written by my coworkers run
any faster.  And when you look at my code, most of it is string
manipulation.  Functions such as gsub() are part of the string library, not
the virtual machine.  So I'm bound by the speed of the C code that
implements gsub() more than the speed of the virtual machine to call that
function.  Someone else who spends more time doing numerical calculations
might end up with different results.

As far as making Lua do native code compilation, the same issues apply.  A
native code compiler would only speed up Lua code, not libraries and other
code called by Lua.  For some people that might speed them up.  Others
would see only a modest increase in speed.  (This can be seen in other
languages-- I know a programmer who in the early days of Java lamented that
there was no native code compiler.  When JIT and native code compilers came
out, he was initially excited but later found that some of his programs
didn't speed up as much as he expected.  The problem was in his case
garbage collection.  His applications generated and destroyed zillions of
objects, and the predominate time in his program's execution was spent in
the memory allocation and garbage collection code-- part of the runtime
environment.)

What may be useful (or at least interesting) is for people to enable
profiling and run real-world Lua programs.  Then, take the topmost
functions (say, those that account for 80% of the program's execution time)
and post them here in this mailing list.  Such a list would likely show a
handful of functions that dominate most of a Lua's program's execution, and
these would be the first candidates for optimization.