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

[Daniel J Guinan]

This conversation, below, is very interesting.  It is precisely this
part of QEMU that fascinates me and potentially holds the most promise
for performance gains.  I have even imagined using a genetic algorithm
to discover optimal block-sizes and instruction re-ordering and
whatnot.  This could be done in order to generate translation tables of
guest instruction sequences and host translated instruction sequences.
Even if  only a handful of very common sequences were translated in
this fashion, the potential speedups are enormous.

Before even discussing the exotic possibilities, however, we need to
figure out what is possible within the framework of the current QEMU
translation system.  Rewiring QEMU to support translating sequences
(blocks of instructions) rather than single instructions may or may not
be necessary.  It should be rather simple to instrument QEMU to keep
track of the most common sequences in order to figure out if there are,
in fact, sequences that show up with a high enough frequency to make
this endeavor worthwhile (I would think the answer would be yes). 
Then, someone skilled in machine code for the host and guest could take
a stab at hand-coding the translation for the most common couple of
sequences to see how the performance gains come out.

I would love to see some work in this direction and would be willing to
help, although my skills are limited in x86 machine.

-Daniel

> One thought would be to have a peephole optimizer that looks back
> over
> the just translated basic block (or a state machine that matches such
> sequences as an on-line algorithm) and match against common, known
> primitive sequences, and replaces them with optimized versions.
> 
> The kind of profiling you would want to do here is to run, say,
> windows
> and take a snapshot of the dynamic code cache, and look for common
> instruction sequences. Ideally, you could write some software to do
> this
> automatically.
> 
> Anyway, I'm sure there are lots of other ideas laying around.
> 
> 
> -- John.
> 
> Another thing I've thought about is checking what sequences of 
> instructions often appear in x86 programs (such as e.g. "push %ebp; 
> movl %esp, %ebp") and then creating C-functions which emulate such an
> 
> antire block, so they can be optimized as a whole by gcc. That would 
> give a similar performance gain on all supported targets, and not
> just 
> on the one you created the peephole optimizer for (+ less work to 
> debug).
> 
> The only possible downside is that you can't jump to a particular 
> instruction in such a block (the same goes for several kinds of 
> peephole optimizations though). I don't know yet how Qemu exactly
> keeps 
> track of the translations it has already performed, whether it
> supports 
> multiple existing translations of the same instruction and/or whether
> 
> it can already automatically invalidate the old block in case it
> turns 
> out it needs to be splitted and thus re-translated (I guess it should
> 
> at least some of these things, since it theory an x86 could jump into
> 
> the middle of an instruction in order to reinterpret the bytes as 
> another instruction stream).
> 
> 
> Jonas
> 
> 
> Unfortunately it's not that simple. The push instruction may cause an
> 
> exception. Whatever optimizations you apply you've got to make sure
> that the 
> guest state is still consistent when the exception occurs.
> 
> Paul
> 
> 
> If we just concatenate the C code of the two procedures, won't gcc
> take 
> care of that for us? Or could scheduling mess this up? Maybe there's
> a 
> switch to avoid having it reschedule instructions in a way that side 
> effects happen in a different order? (that would still give us the 
> advantage of CSE and peephole optimizations)
> 
> 
> Jonas
>