From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HdSxS-0004I7-Dw for qemu-devel@nongnu.org; Mon, 16 Apr 2007 11:17:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HdSxQ-0004HI-Br for qemu-devel@nongnu.org; Mon, 16 Apr 2007 11:17:33 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HdSxQ-0004HD-6u for qemu-devel@nongnu.org; Mon, 16 Apr 2007 11:17:32 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HdSsn-0007vD-0h for qemu-devel@nongnu.org; Mon, 16 Apr 2007 11:12:45 -0400 From: Paul Brook Subject: Re: [Qemu-devel] time inside qemu Date: Mon, 16 Apr 2007 16:12:39 +0100 References: <459540A8.8020209@uab.cat> <200612291810.41992.paul@codesourcery.com> <46238B18.1080308@uab.cat> In-Reply-To: <46238B18.1080308@uab.cat> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704161612.40523.paul@codesourcery.com> 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 Cc: Marius Monton On Monday 16 April 2007 15:41, Marius Monton wrote: > > Any benchmark/performance measurements you make inside qemu are > > meaningless. qemu performance bears no relation whatsoever to the > > performance characteristics of real hardware. > > That's true, and I don't care about it. I'd like to get a method to > stop/start time inside qemu in order to simulate execution of large > pieces of hw out of qemu (look at qemu-systemc project). > If qemu is freeze meanwhile a systemc simulation is in progress > (simulating a HW device of system), time should be freeze also. > In this way, execution time of a program inside qemu should appear > shorter when using accelerator HW than only SW application. I know these > times are not reals, but it should be enough to estimate correctness and > execution time on real platforms. You're deluding yourself. I simply don't believe you can get any meaningful performance measurements out of qemu. You certainly can't use it to evaluate the correctness of time sensitive algorithms. qemu execution times can easily be orders of magnitude different from real hardware. i.e. if you have two operations that take the same amount of time to execute on real hardware, one of those operations may take many times longer than the other inside qemu. If nothing else you're entirely at the mercy of the host OS process scheduler and signal delivery. The emulated CPU may stall for an arbitrary time at any point. Paul