lua-users home
lua-l archive

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


On 5 April 2017 at 22:28,  <gz@tset.de> wrote:
> Am 2017-04-04 18:10, schrieb Luiz Henrique de Figueiredo:
>
>> It's mostly the order the opcodes are listed in the enum defined in
>> lopcodes.h.
>> A switch whose cases are in increasing order should be easily handled by
>> the C compiler, which can generated a simple jump table. More generally,
>> if the cases form an interval [1,n] with n small, then a simple jump
>> table works, even if the cases are not ordered.
>
>
> And the compiler does so quite efficiently. After stumbling upon this old
> paper:
>
> https://www.jilp.org/vol5/v5paper12.pdf
>
> I had a go at making the core vm loop of lua 5.3.4 into a direct threaded
> interpreter. The change itself was pretty easy, basically it involved
> turning the big switch statement in luaV_execute() into a jumptable and a
> goto. This did result in a speedup, but the results are less than
> spectacular. On the average, a speedup of about 3% has been gained across a
> selection of benchmarks from here:
> http://benchmarksgame.alioth.debian.org/u64q/lua.html (with output and gc
> turned off), but for some cases the modified interpreter was even a little
> bit slower than the vanilla lua interpreter. An interesting observation was
> that the distribution of speedups across the benchmarks were quite different
> on the 2 different processors I could test this on, although the average was
> the same.

I'd be interested in seeing your patch. Have you uploaded it anywhere?


> So, in conclusion, this was an interesting exercise, but compilers and
> processors have advanced quite a bit since the paper was written, and so the
> results are not worth maintaining a custom code base.

As far as I understand it, this should have been a relatively easy
change to make and maintain; lvm.c has #defines ready for you to make
such a modification (vmdispatch, vmcase, vmbreak).
https://www.lua.org/source/5.3/lvm.c.html#vmdispatch