From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 806 invoked by alias); 18 Dec 2009 10:33:48 -0000 Received: (qmail 790 invoked by uid 22791); 18 Dec 2009 10:33:47 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from ey-out-1920.google.com (HELO ey-out-1920.google.com) (74.125.78.150) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Dec 2009 10:33:43 +0000 Received: by ey-out-1920.google.com with SMTP id 4so590659eyg.42 for ; Fri, 18 Dec 2009 02:33:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.26.140 with SMTP id e12mr9753172ebc.0.1261132420639; Fri, 18 Dec 2009 02:33:40 -0800 (PST) In-Reply-To: References: <5e81cb500912040734u5ce67afdpd6a2d0e63173f908@mail.gmail.com> <5e81cb500912141840s389859c2r9c56dd8800adb731@mail.gmail.com> <5e81cb500912142326t1bd545ek9180661d8bac10fe@mail.gmail.com> <4B2752C6.4050804@undo-software.com> <5e81cb500912161826j290a3650o999af91f93d4bddf@mail.gmail.com> <4B2A8DE9.5050200@vmware.com> Date: Fri, 18 Dec 2009 10:33:00 -0000 Message-ID: <5e81cb500912180233w9c64972wb1fb60d76584ed0b@mail.gmail.com> Subject: Re: UndoDB's performance From: Sean Chen To: Hui Zhu 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: 2009-12/txt/msg00116.txt.bz2 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. --=20 Best Regards, Sean Chen