[Qemu-devel] Idea for speed improvement

[Qemu-devel] Idea for speed improvement

[Johannes Schindelin]

Hi,

how about the following scenario: We add a "-profile <filename>" option to
QEmu, which just writes out profiling data:

- all the (optimized) intermediate stages of all the translated blocks are
  written into that file.
- the first op will be op_incr_tb_usage_counter, which increments a
  counter in the TB structure.
- whenever a TB is flushed, the counter is written into that file also.

After one run with "-profile", a tool can analyze that data, and generate
a header file which inlines the most frequent sequences to produce new
op_* functions, and code for the optimization phase of the dynamic
translation, which collapses those sequences to the newly created ops.

Then, QEmu is compiled anew, using that code.

This all depends on gcc doing a good job at optimizing the hell out of
those sequences, of course.

Just op_exit_tb cannot be inlined like that, because of the stack problem
I mentioned earlier on this list.

Thoughts, comments, bashing?

Ciao,
Dscho

P.S.: Fabrice, is this what you meant by "gcc backend"?

RE: [Qemu-devel] Idea for speed improvement

[Andreas Bollhalder]

Looks fine ;-) Would GCC sort
for example a case statement,
that the most used op-codes
will be the first entry ?
Could shurly save some cycles.
Or maybe I'm totaly wrong ?

Andreas

-----Original Message-----
From:
qemu-devel-bounces+bolle=geodb
.org@nongnu.org
[mailto:qemu-devel-bounces+bol
le=geodb.org@nongnu.org] On
Behalf Of Johannes Schindelin
Sent: Wednesday, October 06,
2004 4:19 PM
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Idea for
speed improvement


*This message was transferred
with a trial version of
CommuniGate(tm) Pro*
Hi,

how about the following
scenario: We add a "-profile
<filename>" option to
QEmu, which just writes out
profiling data:

- all the (optimized)
intermediate stages of all the
translated blocks are
  written into that file.
- the first op will be
op_incr_tb_usage_counter,
which increments a
  counter in the TB structure.
- whenever a TB is flushed,
the counter is written into
that file also.

After one run with "-profile",
a tool can analyze that data,
and generate
a header file which inlines
the most frequent sequences to
produce new
op_* functions, and code for
the optimization phase of the
dynamic
translation, which collapses
those sequences to the newly
created ops.

Then, QEmu is compiled anew,
using that code.

This all depends on gcc doing
a good job at optimizing the
hell out of
those sequences, of course.

Just op_exit_tb cannot be
inlined like that, because of
the stack problem
I mentioned earlier on this
list.

Thoughts, comments, bashing?

Ciao,
Dscho

P.S.: Fabrice, is this what
you meant by "gcc backend"?



______________________________
_________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailma
n/listinfo/qemu-devel

RE: [Qemu-devel] Idea for speed improvement

[Johannes Schindelin]

Hi,

On Wed, 6 Oct 2004, Andreas Bollhalder wrote:

> Looks fine ;-) Would GCC sort
> for example a case statement,
> that the most used op-codes
> will be the first entry ?
> Could shurly save some cycles.
> Or maybe I'm totaly wrong ?

I am doubtful there is much room there. The op_* functions are kept as
simple as can be, so that much of the operations can be done using
registers only. But there might be room elsewhere.

BTW, you do read your emails on a C64, don't you? Interested in a
target-6510? ;-)

Ciao,
Dscho

RE: [Qemu-devel] Idea for speed improvement

[Andreas Bollhalder]

Hello Johannes

> I am doubtful there is much
room there. The op_* functions
are kept as
> simple as can be, so that
much of the operations can be
done using
> registers only. But there
might be room elsewhere.

Ok, was only a late night
idea.

> BTW, you do read your emails
on a C64, don't you?
Interested in a
> target-6510? ;-)

Not really reading emails, but
I had one for three years from
1986 on ;-) If QEmu will and
can go on the level of
M.E.S.S. (http://mess.org).
The C64 system is shurly less
complex then a i386 one.
Unortunatly, I'm using a
bloated Outlook because the
company where I work tells me
to do. My other PC's are 7
years or older and runs either
on Linux (NO GUI, only CLI)
and FreeDOS / GEOS (still
limited for some internet
stuff).

Greetings

Andreas

______________________________
_________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailma
n/listinfo/qemu-devel