From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DYXv4-0005aU-3V for qemu-devel@nongnu.org; Wed, 18 May 2005 19:25:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DYXty-00050b-Mj for qemu-devel@nongnu.org; Wed, 18 May 2005 19:24:34 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DYXsM-0003f5-PD for qemu-devel@nongnu.org; Wed, 18 May 2005 19:22:54 -0400 Received: from [212.250.162.16] (helo=mta08-winn.mailhost.ntl.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DYXkg-0002uR-TA for qemu-devel@nongnu.org; Wed, 18 May 2005 19:14:59 -0400 Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050518230636.EJSL26549.mta08-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com> for ; Thu, 19 May 2005 00:06:36 +0100 Received: from [192.168.123.103] (really [213.106.86.207]) by aamta08-winn.mailhost.ntl.com with ESMTP id <20050518230636.RDAR18138.aamta08-winn.mailhost.ntl.com@[192.168.123.103]> for ; Thu, 19 May 2005 00:06:36 +0100 Message-ID: <428BCA43.6010601@manchester.ac.uk> Date: Thu, 19 May 2005 00:05:39 +0100 From: Ian Rogers MIME-Version: 1.0 Subject: Re: [Qemu-devel] [patch] gcc4 host support References: <200505112204.10204.paul@codesourcery.com> <1116449710.25594.81.camel@localhost.localdomain> <036001c55bf0$a9aa34f0$334d21d1@organiza3bfb0e> <200505182337.43559.paul@codesourcery.com> In-Reply-To: <200505182337.43559.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Paul Brook wrote: >I know I'd seen something like this before, thanks for reminding me. > >There are several issues with PearColator/RVM: > >- It's written in java. qemu is written in C, so a lot of porting would be >required to get anything working. >- The best benchmark results are half the speed of qemu, and ten times slower >appears to be a more typical result. >- I can't see an any way of doing an incremental transition. My code generator >coexists with dyngen, allowing a gentle migration away from dyngen. > > The currently published benchmark results are for PearColator with just an optimizing compiler (worst case in Jikes RVM is over 100 compiler stages). We also emulate a TLB in much the same way as PearPC, so comparing us to QEMU fast isn't fair (we generate in the region of 10 instructions for loads and stores whereas QEMU fast can generate 1). Our best results are for things that sit in dynamic code for a long period of time, which isn't too surprising. We are working on equivalent results to QEMU fast, but our approach is different to that of QEMU and I completely agree that trying to get QEMU/PearColator to co-exist wouldn't be that great. Regards, Ian Rogers