Re: 5.1 a little slower than 5.0.2

[Mike Pall <mikelu-0409@...>]

Hi,

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:

  http://www.complang.tuwien.ac.at/papers/

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:

http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_4.html

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

http://www.artima.com/intv/choices.html

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.

Bye,
     Mike