From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19T3Ho-0005sk-2y for qemu-devel@nongnu.org; Thu, 19 Jun 2003 13:33:24 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19T3HN-0005AC-Jn for qemu-devel@nongnu.org; Thu, 19 Jun 2003 13:33:00 -0400 Received: from falcon.skarpodata.com ([193.45.208.6] helo=griffin.skarpodata.com) by monty-python.gnu.org with esmtp (Exim 4.20) id 19T3Fa-0003gc-OC for qemu-devel@nongnu.org; Thu, 19 Jun 2003 13:31:06 -0400 Received: from falcon.skarpodata.com (root@[164.9.187.2]) h5JHRsjB010973 for ; Thu, 19 Jun 2003 19:27:54 +0200 Received: (from mailgw@localhost) by falcon.skarpodata.com (8.9.3/8.9.3) id TAA18201 for ; Thu, 19 Jun 2003 19:31:05 +0200 Date: Thu, 19 Jun 2003 19:31:09 +0200 From: Johan Rydberg Subject: Re: [Qemu-devel] tests with simulated memory Message-Id: <20030619193109.6da55741.jrydberg@night.trouble.net> In-Reply-To: <3EF1E5EB.4060204@free.fr> References: <20030619170256.6ee32716.jrydberg@night.trouble.net> <3EF1E5EB.4060204@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , To: qemu-devel@nongnu.org Fabrice Bellard wrote: : Some days ago I looked for a benchmark to publish QEMU objective results : (gzip is not enough!). The BYTEmark you mention seems a good start. SPEC : benchmarks are less interesting since their source code cannot be easily : distributed. Yes. And the Linux nbench testsuite is based on BYTEmark. I used the sources from byte's website. Maybe you should try nbench instead. : I would have expected the slowdown to be more important. In the code you : submitted you did not include alignment tests. Hopefully by just anding : the address with '0xffff0003' you do both address translation _and_ : unaligned access handling... I was a bit suprised aswell. It though you would get a slowdown of something like 2x - 8x, esp since x86 programs does a lot of memory accesses. Regarding alignment checks. I'm not sure it is needed for the x86 platform though, since it supports unaligned memory accesses. (but there is some bit that enabled alignment checks, isn't there?) : It seems that Valgrind is twice as fast on most tests. Some : optimisations will be needed in qemu to correct that :-) Hehe. I was a bit suprised by the result. I thought QEMU would perform better, esp since it must spend less time decoding and more time executing than Valgrind (doing the register allocation + improvements of the micro operations isn't cheep). -- Johan Rydberg, Free Software Developer, Sweden http://rtmk.sf.net | http://www.nongnu.org/guss/ Playing Track No09