qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: ian.rogers@manchester.ac.uk
Subject: Re: [Qemu-devel] Profiling Qemu for speed?
Date: Mon, 18 Apr 2005 15:40:53 +0100	[thread overview]
Message-ID: <200504181540.54145.paul@codesourcery.com> (raw)
In-Reply-To: <95a144a538f61473783743fa426580a0@axiros.com>

On Monday 18 April 2005 14:44, Daniel Egger wrote:
> On 18.04.2005, at 11:51, Ian Rogers wrote:
> > I'm not sure if you can get GCC to generate code sequences like this,
> > but you probably at least need to use the -fprofile-generate and
> > -fprofile-use options
> > http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
>
> Feedback optimisation (FDO) will not work for two reasons:
> a) qemu itself is something like a realtime compiler so FDO
>     will only speed up the compiler but not the generated code
> b) FDO will only provide speed boosts if the feedback phase
>     has a chance to analyse a representative work pattern that
>     is hopefully also repetitive
>
> After all FDO is mostly about making a tradeoff size/speed
> and rearranging code (mostly branches) to avoid branch
> mispredictions of the CPU.

IMHO Profile feedback (in fact any compiler optimizations) are unlikely to 
provide any benefit for qemu itself.

However profile feedback can be useful once we start making the dynamic 
translator smarter. In particular profile information can be used to 
determine how hard to try optimizing the generated code. For code that is 
executed rarely we want to generate it as quickly as possible, for code that 
is executed may times we can afford the extra overhead to make the resulting 
code faster. I've seen measuremets that indicate most code is either executed 
once, or is executed many many times.

With current qemu it doesn't make all that much difference as we only have the 
quick-and-dumb code generator.

Paul

  parent reply	other threads:[~2005-04-18 14:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-18  8:35 [Qemu-devel] Profiling Qemu for speed? Daniel J Guinan
2005-04-18  9:51 ` Ian Rogers
2005-04-18 13:44   ` Daniel Egger
2005-04-18 14:12     ` Christian MICHON
2005-04-18 14:29       ` Ian Rogers
2005-04-18 14:19     ` Ian Rogers
2005-04-18 14:40     ` Paul Brook [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-04-18 11:24 Daniel J Guinan
2005-04-17  5:58 Joe Luser
2005-04-17  8:21 ` John R. Hogerhuis
2005-04-17  8:59   ` Jonas Maebe
2005-04-17 10:27     ` Paul Brook
2005-04-17 10:46       ` Jonas Maebe
2005-04-18  1:36         ` Nathaniel G H
2005-04-18  2:11           ` John R. Hogerhuis
2005-04-18  2:39           ` André Braga
2005-04-18  4:31             ` Karl Magdsick
2005-04-17 10:36 ` Paul Brook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200504181540.54145.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=ian.rogers@manchester.ac.uk \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).