From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MrtEB-0002Ax-Cz for qemu-devel@nongnu.org; Sun, 27 Sep 2009 08:51:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MrtE9-0002Af-SX for qemu-devel@nongnu.org; Sun, 27 Sep 2009 08:51:47 -0400 Received: from [199.232.76.173] (port=41584 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MrtE9-0002Ac-Km for qemu-devel@nongnu.org; Sun, 27 Sep 2009 08:51:45 -0400 Received: from hall.aurel32.net ([88.191.82.174]:43783) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MrtE9-000667-2m for qemu-devel@nongnu.org; Sun, 27 Sep 2009 08:51:45 -0400 Date: Sun, 27 Sep 2009 14:51:39 +0200 From: Aurelien Jarno Subject: Re: [Qemu-devel] [PATCH][RFC] x86: use globals for CPU registers Message-ID: <20090927125139.GA30054@volta.aurel32.net> References: <761ea48b0909131400i33efc212nce026adb75a4f5d2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <761ea48b0909131400i33efc212nce026adb75a4f5d2@mail.gmail.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Desnogues Cc: qemu-devel@nongnu.org On Sun, Sep 13, 2009 at 11:00:08PM +0200, Laurent Desnogues wrote: > Hello, > > this patch is a proposal to use globals for the 8 or 16 CPU > registers on i386 and x86_64. > > I measured the improvement in the following conditions: > > - Machine: i7 920 > - Software: Fedora11 x86_64 gcc 4.4.1 > - Benchmark: SPEC2000 gcc with expr.i input > - User mode > - i386 and x86_64 hosts and targets, with and without the patch > (8 combinations) > > The results are: > > qemu-i386_on-i386 15.82user 0.05system 0:15.91elapsed > qemu-i386_on-i386-reg 15.40user 0.02system 0:15.43elapsed > qemu-i386_on-x86_64 15.65user 0.05system 0:15.71elapsed > qemu-i386_on-x86_64-reg 15.11user 0.03system 0:15.15elapsed > qemu-x86_64_on-i386 mmap: No such device or address > qemu-x86_64_on-i386-reg mmap: No such device or address > qemu-x86_64_on-x86_64 18.42user 0.07system 0:18.49elapsed > qemu-x86_64_on-x86_64-reg 13.22user 0.06system 0:13.31elapsed > > Given my lack of knowledge of system QEMU, I will leave it to > someone else to measure the speedup. > Here are my benchmarks in system mode. I measured the improvement in the following conditions: - Machine: Intel Core 2 Quad Q9450 with 8GB RAM - Intel Speedstep disabled - Host: Debian Sid amd64 (kernel 2.6.31, gcc 4.3, glibc 2.9) - Benchmark: boot time, compilation of small C++ application - Guests: Debian Lenny amd64 and i386, preloaded into memory with readahead. +-------------+-------+-------+-----------+------------------+ | qemu target | guest | patch | boot time | compilation time | +-------------+-------+-------+-----------+------------------+ | i386 | i386 | no | 55s | 19.9s | | i386 | i386 | yes | 54s | 19.8s | | x86_64 | i386 | no | 67s | 24.6s | | x86_64 | i386 | yes | 63s | 23.3s | | x86_64 | amd64 | no | 61s | 19.9s | | x86_64 | amd64 | yes | 58s | 18.7s | +-------------+-------+-------+-----------+------------------+ There is always a measurable gain, and even significant gain for qemu-system-x86_64. This is consistent with the user mode benchmarks. The gains are probably less important in system mode due to the chosen benchmarks. I think this patch is clearly a step in the right direction to a clean target-i386 code, and I will be happy to commit it once it has been cleaned. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net