Re: [Qemu-devel] Profiling Qemu for speed?

[Daniel J Guinan]

> > I was up until 3:00am studying Qemu, and I came to the conclusion
> that
> > it doesn't make sense to try speeding up the output code, at least
> not
> > yet. A peephole optimizer or hand-coded sequences made to handle
> common
> > combinations of instructions would lead to the problems discussed
> here:
> > exceptions happening at the right time, self-modifying code, etc.
> 
> Well yeah... I didn't say it would be easy :-)

I would like to suggest that perhaps it would be useful to experiment
anyway.  Self-modifying code cannot be that prevalent (unless you are a
virus writer - which, yes, means that probably any standard Windows
installation of any maturity would stop working ;-), exceptions are
potentially more dangerous and branching into a translated blocks would
need to be dealt with by (probably) retranslating on an
instruction-by-instruction level and then allowing the branch to occur
into the traditional translation.

At any rate, making this a compile-time (or even runtime) option would
allow for basic experimentation.  Until we can go from instruction
translation to logic translation, this system will never fullfill it's
potential.  Instruction translation can maintain the property of system
correctness, which is indeed broken by logic translation (e.g. perhaps
exceptions don't occur when they normally would, or need to be handled
and translated resulting in slightly different behavior).  However, I
would like to assert that with the proper balance and approach, exact
system correctness may not be strictly neccessary (I am thinking of
certain exception cases) and logic translation has the potential to be
wickidly faster (if the PPC can do something in 6 steps that takes an
x86 15 steps, but there is an outside chance of a division by zero
exception, why do it in 87 steps? Shouldn't we at least try to see if
we can make it work in 6? or 12?).

> > Worse, the translator might have to spend so much time doing this
> that
> > the result would actually be slower execution.
> 
> Not if you do it right. Remember. by and large you only incur a
> one-time
> hit, and after that you're going as fast as your dynamic translator
> is
> smart.
> 
> Here's a heuristic for you: optimize for the general case, not corner
> cases. You still have to handle the corner cases, but they are corner
> cases for a reason: you don't run into them as often.

Exactly, as I hinted at in a previous post, it may turn out that some
sequence of (for example) 5 instructions is so common in all software
that the act of hand coding a replacement for those 5 instructions
could result in a noticible overall performance improvement.  And then
you can start scaling the performance up from there.  I will guarantee
that we can find some sequences that do not have problems with
exceptions that would be candidates (guaranteeing on branch and
self-modifying is not as easy).  But not to try? 

-Daniel