From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FnFSH-0005NB-UC for qemu-devel@nongnu.org; Mon, 05 Jun 2006 09:49:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FnFSG-0005Mq-AM for qemu-devel@nongnu.org; Mon, 05 Jun 2006 09:49:17 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FnFSG-0005Mn-6t for qemu-devel@nongnu.org; Mon, 05 Jun 2006 09:49:16 -0400 Received: from [65.74.133.6] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FnFZP-0005qJ-Ju for qemu-devel@nongnu.org; Mon, 05 Jun 2006 09:56:39 -0400 From: Paul Brook Subject: Re: [Qemu-devel] yet another proposed solution for gcc 4.x Date: Mon, 5 Jun 2006 14:49:03 +0100 References: <20060604085935.GB24853@tapir.sajinet.com.pe> <46d6db660606050421y77a65b4ehe253dba7ff8a799e@mail.gmail.com> <20060605134346.GE26124@tapir.sajinet.com.pe> In-Reply-To: <20060605134346.GE26124@tapir.sajinet.com.pe> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606051449.04585.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 (everything compiled with gcc3) > user 0m0.250s > 9.44444 (everything compiled with gcc4) > user 0m0.284s > 9.25806 Your comparison is not valid. You should only change one variable at once. We don't care whether a gcc4 sha1 is faster or slower than gcc3 sha1. By your own numbers gcc4 is slower in absolute terms. We only care whether qemu goes faster or slower when running the same binary. You should also state how any runs you did and what the variation is. Especially on modern systems there can be a lot of variation between successive runs. > PS. is there any "standard" way to benchmark qemu that is all agreed upon as > authoritative other than `make speed`? Not really. Also, simple benchmarks (which tend to be dominated by a single "hot" loop) are not neccly a representative measure of qemu performance. Paul