From: "Leonardo E. Reiter" <lreiter@win4lin.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qvm86, kqemu and video speed
Date: Wed, 13 Apr 2005 16:09:56 -0400 [thread overview]
Message-ID: <425D7C94.3050300@win4lin.com> (raw)
In-Reply-To: <425D71E5.3050807@win4lin.com>
Well the proof is in the pudding as they say. Running the display
adapter benchmark with the Fresh Diagnose program under Windows 2000,
inlining the glue functions actually slows some things down a slight
bit, while improving others by a small margin. Overall there is no
measurable performance gain when the glue functions are inlined. So I
suppose there is no sense in doing that.
Processors these days are so smart, that perhaps the inlining actually
causes cache optimization problems in some cases and has a negative
(instead of the expected positive) performance effect.
- Leo Reiter
Leonardo E. Reiter wrote:
> 3. I think a really simple optimization may be to inline the glue
> functions in vga_template.h, cirrus_vga_rop.h, and cirrus_vga_rop2.h,
> which is very trivial. We tried that a while back and it did improve
> performance a bit - for instance, it shaved 1.5 seconds off the boot
> time of a Windows 2000 session. Windows 2000 likes to display heavy
> graphics, like marquees, etc., while booting in its status dialog boxes,
> which is why the improvement was there I think. Maybe Fabrice or
> someone else can comment as to the possible consequences, other than the
> obvious code size increase of using inline functions (which is not much
> in this case) of inlining those functions. We didn't notice anything
> adverse, but perhaps we weren't looking closely enough :) We will keep
> testing over here, and if all goes well, post a patch that does this
> simple optimization. That is, unless anyone can chime in with a good
> reason not to do this of course.
--
Leonardo E. Reiter
Vice President of Engineering
Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com
next prev parent reply other threads:[~2005-04-13 20:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-11 14:07 [Qemu-devel] qvm86, kqemu and video speed Struan Bartlett
2005-04-11 15:01 ` James Mastros
2005-04-11 15:17 ` Paul Brook
2005-04-11 15:35 ` Struan Bartlett
2005-04-11 21:51 ` Struan Bartlett
2005-04-15 8:54 ` Struan Bartlett
2005-04-12 3:13 ` Darryl Dixon
2005-04-11 21:53 ` Struan Bartlett
2005-04-12 16:38 ` Alex Beregszaszi
2005-04-12 19:30 ` Fabrice Bellard
2005-04-13 3:57 ` use.reply-to.address
2005-04-13 8:06 ` Struan Bartlett
2005-04-13 18:12 ` Hetz Ben Hamo
2005-04-13 19:24 ` Leonardo E. Reiter
2005-04-13 20:09 ` Leonardo E. Reiter [this message]
2005-04-14 9:42 ` Thomas Steffen
2005-04-18 7:32 ` Oliver Gerlich
2005-04-19 6:15 ` emuls
2005-04-13 21:12 ` Jim C. Brown
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=425D7C94.3050300@win4lin.com \
--to=lreiter@win4lin.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.