From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Bierl-0005Yg-IY for qemu-devel@nongnu.org; Thu, 08 Jul 2004 15:47:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Bierk-0005Xf-Mz for qemu-devel@nongnu.org; Thu, 08 Jul 2004 15:47:33 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bierk-0005XV-JW for qemu-devel@nongnu.org; Thu, 08 Jul 2004 15:47:32 -0400 Received: from [216.254.0.204] (helo=mail4.speakeasy.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BiepS-0001KC-1C for qemu-devel@nongnu.org; Thu, 08 Jul 2004 15:45:10 -0400 Subject: Re: [Qemu-devel] Storing code caching From: "John R. Hogerhuis" In-Reply-To: <200407082011.54991.jseward@acm.org> References: <1089306349.12383.1723.camel@aragorn> <431F9EDC-D108-11D8-8B8C-000A95B1EB4C@mac.com> <200407082011.54991.jseward@acm.org> Content-Type: text/plain Message-Id: <1089315912.12383.1777.camel@aragorn> Mime-Version: 1.0 Date: Thu, 08 Jul 2004 12:45:12 -0700 Content-Transfer-Encoding: 7bit Reply-To: jhoger@pobox.com, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: jseward@acm.org, qemu-devel@nongnu.org On Thu, 2004-07-08 at 12:11, Julian Seward wrote: > Nice idea, but ... I suspect it solves a non-problem really. Caching > translations is only worthwhile when translation time is a large > part of overall run time, but I bet that's not the case. It certainly > isn't with Valgrind, which uses similar technology. > Right. That's entirely possible, but just as much speculation without any numbers. No one knows until the work or analysis is done... Translation time is certainly not negligible. And a better code generator would quite likely swamp any improvements a persistent cache could give. There's disk I/O to consider there too. But it is possible the improvements would make a faster emulator. It depends on requirements too I guess. If you don't care about load time then you probably don't care about translation time either since from the user's point of view they are going to be conflated. > If you want to throw lots of hacking effort at QEMU to make it > go faster, I suspect you'll need to be building a more sophisticated > code generator, a la "lcc" (http://www.cs.princeton.edu/software/lcc). Interesting... why do you bring up lcc specifically? Just browsing that page and its FAQ didn't tell me much about it other than it is a retargetable C compiler.