From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HdoeP-000198-UA for qemu-devel@nongnu.org; Tue, 17 Apr 2007 10:27:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HdoeN-00018w-JY for qemu-devel@nongnu.org; Tue, 17 Apr 2007 10:27:20 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HdoeN-00018r-CL for qemu-devel@nongnu.org; Tue, 17 Apr 2007 10:27:19 -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 1HdoZd-0003LL-EI for qemu-devel@nongnu.org; Tue, 17 Apr 2007 10:22:25 -0400 From: Paul Brook Subject: Re: [Qemu-devel] time inside qemu Date: Tue, 17 Apr 2007 15:22:16 +0100 References: <459540A8.8020209@uab.cat> <200704161612.40523.paul@codesourcery.com> <4624D442.7000406@uab.cat> In-Reply-To: <4624D442.7000406@uab.cat> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704171522.17849.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 > code (a) : for (int i = 0; i< 1000000; i++) c[i] = a[i] * b[i]; > > code (b) : for (int i = 0; i< 1000; i++) for(int j = 0; j < b[i]; j++) > c[i] += a[i]; > > code (c) : for (int i = 0; i< 1000; i++) c[i] = HW_MUL(a[i], b[i]); > > I'm sure that code (b) will execute much longer that code (a) inside > qemu (sure that different that in real platform), and I'd like to > compute executing time for code (c) in some way. > So, how can I trap time information/calculation inside qemu? You can't. As I've said before, any performance measurements you make inside qemu are completely meaningless. You may be able to say that executing 1000 iterations takes longer than 10 iterations of the same loop, but you didn't need a simulator to tell you that. Also, there's a good chance qemu will take almost exactly the same time to execute them because the execution time will be dominated by the translation time for the first iteration. You can not compare the cost of (say) add v.s. multiply, or of two different multiply instructions. The timings for the individual instructions (or any particular sequence of instructions) bear no relation whatsoever to the timings for the same sequence on real hardware. I'm repeating myself now, so I intend this to my my last response to this thread. Paul