Re: Suggestions on implementing an efficient instruction set simulator in LuaJIT2

[Josh Haberman <jhaberman@...>]

Josh Haberman <jhaberman <at> gmail.com> writes:
> Mike Pall <mikelu-1102 <at> mike.de> writes:
> > Alex Bradbury wrote:
> > > So at its core, it's just a loop which fetches each instruction,
> > > decodes it and then does a switch on the opcode number. The
> > > performance numbers I've managed so far aren't competitive with the C
> > > implementation and I'm interested in suggestions for improving that.
> > 
> > The main loop of an interpreter is a tough job for compilers (and
> > CPUs). Most interpreters have been written in C, so C compilers
> > have been tuned for this case over the years. They still generate
> > mediocre code, compared to what you can achieve in assembler.
> 
> Could you possibly summarize the few biggest strategies that you
> use to beat C compilers when it comes to interpreter loops?  I'm
> really interested in this problem.  I can (and do) read the LuaJIT
> code, but that doesn't tell me what was deficient about the original
> compiler output.

Hmm, this probably seems overly broad.  Maybe a better question
to ask would be: what do compilers still suck at, in the context
of interpreter main loops?  Common wisdom is that compilers these
days are so good that a human can rarely ever beat them.  Clearly
that's wrong in the case of LuaJIT, but how so?  What bad decisions
do compilers make in interpreter loops?

Josh