From: Jamie Lokier <jamie@shareable.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] OSX x86_32 host support
Date: Tue, 15 Jan 2008 16:52:47 +0000 [thread overview]
Message-ID: <20080115165246.GB16677@shareable.org> (raw)
In-Reply-To: <478CE001.4000907@csgraf.de>
Alexander Graf wrote:
> Jamie Lokier wrote:
> > Alexander Graf wrote:
> >> I believe the 5% performance hit
> >> that goes with them is no real problem, as most people should be using
> >> x86_64 nowadays anyway.
> >
> > *Boggle*! x86_64 is only a few years old, and cheap low-power x86_64
> > laptops are relatively recent.
> >
> So you really want to do dynamic retranslation on ancient hardware?
I think you are using 'ancient' to mean what I call 'relatively
recent'.
I bought my current main machine just 1.5 years ago, and there were
_no_ fast 64-bit low power laptop CPUs available at the time. I
hardly call 1.5 years ancient. Now there are chips available, but the
overall improvement isn't enough to justify paying to replace a good
1.5 year old machine yet.
> To me emulated systems already feel slow on really recent machines,
> I don't want to go back to something even slower.
No problem with your experience, and you're right about the speed of
course. I only object to generalising that, to say that nearly
everyone _should_ be using x86_64 now, and (by implication) that
x86_32 is no longer relevant and should get second class support. It
seems to imply that only people who buy a new computer every 2 years
(at most) use Qemu. But Qemu is used for lots of different things,
and on lots of machines. It'll be a few more years before 32-bit Qemu
users are a rarity, imho.
> If you use kqemu there even is near no performance hit at all, which I
> believe is the main use of qemu on i386 anyway.
It's also the main use of Qemu on x86_64, so irrelevant point :-)
> Furthermore x86_64 is _way_ faster, as it provides a lot more
> registers.
For some loads, x86_64 is slower because it uses more memory for
pointers. But really, the actual relative speed of 32/64 x86 is quite
offtopic. It's the idea that people "should" use x86_64 with Qemu and
therefore 32-bit x86 should be a second class platform that I object
to. I don't think it's time for that yet.
> I think the benefit you get from cutting the gcc3 dependency is way more
> important than a major performance hit that people will usually only see
> on the next release of qemu, by which time things have shifted towards
> x86_64 even more.
This I agree with. Cutting the gcc3 dependency is good, even if it
costs a little in performance. Clearly, the best performance would
come from a different kind of code generation backend which understood
the host CPU directly, not depending on GCC code fragments at all.
-- Jamie
next prev parent reply other threads:[~2008-01-15 18:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-13 23:43 [Qemu-devel] [PATCH] OSX x86_32 host support Mike Kronenberg
2008-01-14 8:25 ` Alexander Graf
2008-01-14 8:48 ` Mike Kronenberg
2008-01-15 13:14 ` Jamie Lokier
2008-01-15 16:32 ` Alexander Graf
2008-01-15 16:52 ` Jamie Lokier [this message]
2008-01-15 16:56 ` Johannes Schindelin
2008-01-15 17:30 ` Andreas Färber
2008-01-15 17:50 ` Alexander Graf
2008-01-15 18:11 ` Alexander Graf
2008-01-15 18:23 ` Thiemo Seufer
2008-01-15 18:51 ` Alexander Graf
2008-01-15 19:10 ` Andreas Färber
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=20080115165246.GB16677@shareable.org \
--to=jamie@shareable.org \
--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).