lua-users home
lua-l archive

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


Roberto Ierusalimschy wrote:
> > Another few percent may be gotten by using the proper -march= GCC option
> > (many distros still set the default to pure 80386 code).
> I tried that and got mixed results. As far as I remember I got a
> worse performance in some cases when using that option :(
> (But that was some versions of gcc ago. I will try that again...)

It seems to depend a lot on which other optimization options are used.
Even given a representative benchmark (which is hard enough to find),
finding the best set of options for a specific machine is difficult.
GCC has an abundance of options, so someone used a genetic algorithm (!)
to solve this problem (search for "ACOVEA"). =8-)

[ Roberto probably knows these papers already, but for anyone interested: ]

More can be gained by tuning the virtual machine. Good papers for the
pure interpreter approach are at:

The EG03 paper is a nice introduction to the subject.

Of course a JIT compiler would be even faster. But compiling Lua requires
dynamic type inferencing and massive inlining to gain acceptable speeds.
This is anything but trivial.

Here is a link to a part of a whitepaper about the Java Hotspot JIT engine:

And something about the CLR (.NET and C# target) JIT engine:

Since I'm quite satisfied with the speed of the Lua VM, I have no
motivation to improve it (right now). Modifying the VM to use the GCC
"labels as values" feature (void *jumptab[]={&&opcode1,...} and
goto *(jumptab[opcode])) would be an interesting experiment, though.
But I think it may be difficult for register starved machines (i.e. x86)
to keep all important variables (pc, base and maybe cl) in registers.