[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] OSX x86_32 host support

From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH] OSX x86_32 host support
Date: Tue, 15 Jan 2008 20:10:39 +0100

Am 15.01.2008 um 18:50 schrieb Alexander Graf:

On Jan 15, 2008, at 6:30 PM, Andreas Färber wrote:

Am 15.01.2008 um 17:32 schrieb Alexander Graf:

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.

-- Jamie

So you really want to do dynamic retranslation on ancient hardware? To
me emulated systems already feel slow on really recent machines, I
don't  want to go back to something even slower.
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. Furthermore x86_64 is
_way_ faster, as it provides a lot more registers.

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.

One thing you don't seem to understand is that QEMU releases don't upgrade our hardware, especially not from Apple. An x86_64 Mac Pro is more than double the price for my PowerMac G5 back then. Don't think about what people "should" be using in your opinion, look at what they are actually using.

What I am actually talking about is that the only real gcc4 breakage I am aware of is on i386. I just built x86_64-softmmu on a POWER6 host with gcc4.1.2 and it "simply worked". Please tell me if there is anything broken for you on gcc4. I believe there isn't (please use gcc4.2+).

People want to run software, including Q or QEMU, on their hard- and software, which may include ppc hardware as well as Panther/ Tiger operating systems ... both much more "ancient" than Intel Core 2 Duo based Macs. And yes, it's "slow". Does that stop me? No. And you likely don't have a kqemu on your Mac either. Occasionally trying an image does not justify buying VMware Fusion, and such commercial products only do virtualization anyway and are incapable of emulating different hardware. Just in case you forgot, Open Source software in general usually has the benefit of not being tied to the support lifetimes of commercial vendors, forcing users to upgrade their (e.g. Windows) OS - but pushing us to upgrade our hardware as soon as something faster is out would be doing exactly that hardware-wise, without substantial reason.

I wasn't talking about PowerPC. I am really sorry if it looked that way, but it was neither my intention nor my belief to say anything against any platform but i386.

I didn't get you wrong. You repeatedly said that virtually no-one were using i386 Macs any longer and that they were ancient. This implies that ppc Macs are pre-ancient by linearity of time.

I am not feeling personally insulted as a ppc and i386 user. I am simply trying to show that there are in fact even older things still in quite common use than what you called "ancient".

The important point to note here is that those i386 Macs need GCC4 anyway, so there is no other option than some working GCC4 solution for i386 and x86_64 on Intel Macs. This seems to go missing when discussing availability of chips and PC laptops, where gcc3 is an option. What we seem to agree on is that a performance hit on i386 Macs is better than not being able to run on Intel Macs at all - which is the current CVS situation.

To me as a relative outsider it appears (maybe that's wrong) that the core developers, who wrote the original code affected by GCC3/4 ABI changes don't know how to or don't see a pressing need to do the change. Then occasionally someone comes along presenting an all-new GCC4 patch in a hit-and-run manner, not leading to their patches applied or the problem solved...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]