From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6177 invoked by alias); 5 Jan 2010 02:47:52 -0000 Received: (qmail 6169 invoked by uid 22791); 5 Jan 2010 02:47:51 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-iw0-f203.google.com (HELO mail-iw0-f203.google.com) (209.85.223.203) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 Jan 2010 02:47:47 +0000 Received: by iwn41 with SMTP id 41so10888394iwn.12 for ; Mon, 04 Jan 2010 18:47:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.146.2 with SMTP id f2mr786161ibv.23.1262659665122; Mon, 04 Jan 2010 18:47:45 -0800 (PST) In-Reply-To: <5e81cb500912180233w9c64972wb1fb60d76584ed0b@mail.gmail.com> References: <5e81cb500912040734u5ce67afdpd6a2d0e63173f908@mail.gmail.com> <5e81cb500912142326t1bd545ek9180661d8bac10fe@mail.gmail.com> <4B2752C6.4050804@undo-software.com> <5e81cb500912161826j290a3650o999af91f93d4bddf@mail.gmail.com> <4B2A8DE9.5050200@vmware.com> <5e81cb500912180233w9c64972wb1fb60d76584ed0b@mail.gmail.com> From: Hui Zhu Date: Tue, 05 Jan 2010 02:47:00 -0000 Message-ID: Subject: Re: UndoDB's performance To: Sean Chen Cc: Michael Snyder , Marc Khouzam , Greg Law , "gdb@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-01/txt/msg00039.txt.bz2 The idea is not bad. If you can do something is better. :) Thanks, Hui On Fri, Dec 18, 2009 at 18:33, Sean Chen wrote: > On Fri, Dec 18, 2009 at 11:35 AM, Hui Zhu wrote: >> Maybe Marc use the record_wait in linux-nat.c version. >> It will increase the speed a little. >> I did some small test to add some record function to i386-linux-nat.c. >> =A0It will helpful. >> >> The main speed issue is the prec need let the inferior keep single step. >> So the prec skip patch can more helpful. >> And the record part can be more intellective. =A0For example: >> Let record_message decode more than one code. =A0Then we can let >> inferior exec more than one insn for each cycle. >> >> Thanks, >> Hui >> >> >> On Fri, Dec 18, 2009 at 04:00, Michael Snyder wrote: >>> Marc Khouzam wrote: >>>> >>>> My results did seem suspiciously good. =A0Trying things again, I don't >>>> get the same results at all. =A0I don't remember my exact orginal test, >>>> but I know PRecord had a problem with recursion, maybe that is what >>>> skewed the results? >>> >>> That problem with recursion was actually in gdb core, not in precord. >>> As long as you're just executing (ie. not reverse-stepping) it would >>> never have showed up. >>> >>> (and it's fixed now). >>> >>> >> > > Hi Hui, > > I believe the performance of precord will improve a lot with your > strategy. Thanks. > > To record a single instruction (except system call), we need to do the > following three steps > 1. parse the instruction > 2. store the delta status > 3. single step the instruction > > Have you tested the execution time (proportion) of each step? > > If "single step the instruction" takes more than 90% of the overall > execution time, there will be a great space for us to improve the > performance. You know, we are able to decode several instructions each > time, and we are able to decode hundreds of instructions or even more. > We are even able to simulate the behavior of the whole process, in > case we don't need to care about the shared memory. That's, we have > our own simulator inside. Maybe I am too crazy. Anyway, it highly > depends on the proportion of the three steps. > > -- > Best Regards, > Sean Chen >