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

[John R. Hogerhuis]

On Sun, 2005-04-17 at 18:36 -0700, Nathaniel G H wrote:

> 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 :-)

> 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.

> 
> I have another idea: The next-best thing to making faster output is to
> make the same output, faster. In other words, speeding up the
> translator. Given that the bulk of the translator is in disas_insn()
> and all the gen_* functions it calls, this seems like a good place to
> begin.
> 

Why would that be faster? Most of the time you only dynamically
translate code once. Self modifying code, exceptions, are, well,
exceptions.

The lowest hanging fruit right now is probably the cirrus svga
emulation. That will probably make a huge, noticeable difference.

Then like I said I think there is always room to make the dynamic code
generator smarter.

-- John.