qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <andreas.faerber@web.de>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] OSX x86_32 host support
Date: Tue, 15 Jan 2008 20:10:39 +0100	[thread overview]
Message-ID: <8149F563-74D1-4BAF-B9BA-9AFDCF3324FE@web.de> (raw)
In-Reply-To: <B1F2FD32-569D-4445-B8B5-094183EF4062@csgraf.de>


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...

Andreas

      parent reply	other threads:[~2008-01-15 19:11 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
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 [this message]

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=8149F563-74D1-4BAF-B9BA-9AFDCF3324FE@web.de \
    --to=andreas.faerber@web.de \
    --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).