Towards a faster interpreter

[Dibyendu Majumdar <mobile@...>]

Hi,

I have been thinking of ways of making the Ravi interpreter faster
without having to resort to assembly code etc. So far one of the areas
I have not really looked at is how to improve the bytecode decoding.
The main issue is that the operands B and C require an extra bit
compared to operand A, so we cannot make them all 8 bits...

But of course we can - as LuaJIT has done - by creating specialised
bytecodes that can take at most one operand that is a constant, and
the bytecode itself specifies which operand is a constant. Then the
requirement for the extra bit will be gone, allowing all three
operands to be 8-bits. (I was wondering whether any of the arithmetic
or bitwise opcodes ever see two constants at the same time -
presumably not due to constant folding? - something to check ...)

Ravi has a larger bytecode set than Lua 5.3 - doing above will make
the set even larger. However, on the plus side the three operands can
all be 8-bits and the opcode itself can be 8-bits. I guess that having
a larger set of bytecodes will make the VM bigger and that is a
downside.

The other plus for Ravi is that it will be more compatible with Lua
5.3, as some of the limits can be made the same as Lua 5.3.

Another area I am going to look at is how to make table field access
faster. I have done some work on this already by specialising
scenarios where the key is known to be a string or integer, but more
work is needed, especially in inlining the table lookup.

Finally the function call overhead is an area to work on. I did some
informal profiling or Ravi interpreter recently (and I am still
verifying the results) but preliminary findings are that the OP_CALL
bytecode has the largest overhead (not surprising).

All of this work will take some fair amount of time as I cannot spare
much time to work on Ravi at the moment.

I welcome any other tips / suggestions people have regarding
performance optimisation.

Regards
Dibyendu