From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44289 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmrwR-00081y-Dr for qemu-devel@nongnu.org; Tue, 08 Feb 2011 13:05:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmrwQ-0008FP-Df for qemu-devel@nongnu.org; Tue, 08 Feb 2011 13:05:31 -0500 Received: from a.mail.sonic.net ([64.142.16.245]:39765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmrwQ-0008FG-1v for qemu-devel@nongnu.org; Tue, 08 Feb 2011 13:05:30 -0500 Message-ID: <4D5185DA.3050105@twiddle.net> Date: Tue, 08 Feb 2011 10:05:14 -0800 From: Richard Henderson MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 5/7] tcg-i386: Implement deposit operation. References: <1294716228-9299-1-git-send-email-rth@twiddle.net> <1294716228-9299-6-git-send-email-rth@twiddle.net> <20110125122749.GA19736@edde.se.axis.com> <20110131083322.GA17924@volta.aurel32.net> In-Reply-To: <20110131083322.GA17924@volta.aurel32.net> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: "Edgar E. Iglesias" , agraf@suse.de, qemu-devel@nongnu.org On 01/31/2011 12:33 AM, Aurelien Jarno wrote: > This week-end I have tested it emulating an x86-64 machine on x86-64, > with all the patch series applied. I have measured the boot time from > the bootloader up to the graphical environment of a Debian installation > I used -snapshot to make sure the host hard-drive is not introducing any > noise in the measurement (so that the whole image is in the host cache), > and did the measurement 10 times. The machine is a Core 2 Q9650, nothing > else was running on the machine except the few standard daemons. > > I have found that the boot time is roughly 1.8% faster with the patch > series applied. It's undoubtedly an improvement, but still close to the > measurement noise. This is a bit disappointing... It's also not terribly surprising, with that test scenario. GCC tries not to generate partial register stores, except when (as here) it's really a bitfield insert. A test that might show off the deposit code more would be booting a 16-bit OS. Either FreeDOS, or Windows 3.1 (if anyone still has a copy). In that case, the translator will be emitting a deposit op for almost every guest instruction. (Which is probably a mistake from a translator point of view -- there's no reason we can't emulate 16-bit operations with 32-bit operations given that the high bits are ignorable.) r~