Follow-on from does Lua need a JIT - making Lua's interpreter faster

[Dibyendu Majumdar <mobile@...>]

It seems from the majority of responses so far that JIT is not
essential for Lua, or putting it another way, a majority of use cases
can be satisfied without a JIT.

A natural follow on question is can the interpreter be made faster
without resorting to hand-written assembly code or other esoteric
optimisations?

Apart from using type annotations and introducing the numeric array
types in Ravi - which when used do improve interpreter speed - I have
also been experimenting with various other changes.

1. If the Lua stack was fixed in size can that lead to more optimised
code? We need to make sure that the compiler knows about this fact.
2. Can the table get/set be optimised for integer and string access -
preferably inlined? I have been playing with the idea of using a
precomputed 'hashmask' similar to LuaJIT to reduce the instructions
needed to locate a hashed value.
3. What if we give hints to the compiler using the gcc/clang branch
weights feature to help the optimizer generate better code for the
more common scenarios? This is a trade-off as making common cases
faster can penalize other cases.
4. Faster C function calls when the C function does not depend on Lua
and takes 1-2 primitive arguments and returns a primitive argument.
5. If we use a memory allocator such as jemalloc will that help?
6. I have not considered computed gotos because I am not sure of their
benefits especially for Ravi where the number of byte code
instructions is larger than Lua. It may also lead to worse
optimisation in other areas.

I have nothing to report yet as the results from my experiments are
inconsistent across platforms, and I really haven't had the time to do
this seriously.

I would welcome any thoughts on this topic.

Regards
Dibyendu