From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1DNXaQ-0003rl-Vz
	for qemu-devel@nongnu.org; Mon, 18 Apr 2005 10:50:55 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1DNXXs-0003Fn-Uy
	for qemu-devel@nongnu.org; Mon, 18 Apr 2005 10:48:21 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1DNXXm-00035M-Tl
	for qemu-devel@nongnu.org; Mon, 18 Apr 2005 10:48:10 -0400
Received: from [212.250.162.19] (helo=mta13-winn.mailhost.ntl.com)
	by monty-python.gnu.org with esmtp (Exim 4.34) id 1DNXGv-0004m2-93
	for qemu-devel@nongnu.org; Mon, 18 Apr 2005 10:30:45 -0400
Message-ID: <4263C42E.5030108@cs.man.ac.uk>
Date: Mon, 18 Apr 2005 15:29:02 +0100
From: Ian Rogers <irogers@cs.man.ac.uk>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Profiling Qemu for speed?
References: <20050418083542.45378.qmail@web54110.mail.yahoo.com>	<42638306.4050200@cs.man.ac.uk>	<95a144a538f61473783743fa426580a0@axiros.com>
	<46d6db66050418071228139ffd@mail.gmail.com>
In-Reply-To: <46d6db66050418071228139ffd@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: ian.rogers@manchester.ac.uk, qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Christian MICHON <christian.michon@gmail.com>, qemu-devel@nongnu.org

Christian MICHON wrote:

>I did months ago gcc/FDO with a xp/lite installation as a "repetitive task" :)
>I did not improve the timings after all the effort.
>  
>
could this be down to the tables used to find the 
translators/generators? are they constant? is it possible to make them 
amenable to feedback directed analysis? x86 is also an odd case, it 
could be that load-store architectures with more registers notice FDO 
more as the x86 can access the L1 caches similarly to a large register 
file. If the problem is gcc's feedback analysis then you could always 
try Intel's compiler. Regards,

Ian Rogers
-- http://www.binarytranslator.org/