From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2642 invoked by alias); 17 Dec 2009 14:41:21 -0000 Received: (qmail 2633 invoked by uid 22791); 17 Dec 2009 14:41:19 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 Dec 2009 14:41:12 +0000 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nBHEfskx008891; Thu, 17 Dec 2009 08:41:54 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.228]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 17 Dec 2009 09:41:08 -0500 From: Marc Khouzam To: "'Sean Chen'" CC: "'Greg Law'" , "'Hui Zhu'" , "'gdb@sourceware.org'" Date: Thu, 17 Dec 2009 14:41:00 -0000 Subject: RE: UndoDB's performance Message-ID: References: <5e81cb500912040734u5ce67afdpd6a2d0e63173f908@mail.gmail.com> <5e81cb500912140518r2ad3f2fdrd0dd5a546e6d8a33@mail.gmail.com> <5e81cb500912141840s389859c2r9c56dd8800adb731@mail.gmail.com> <5e81cb500912142326t1bd545ek9180661d8bac10fe@mail.gmail.com> <4B2752C6.4050804@undo-software.com> <5e81cb500912161826j290a3650o999af91f93d4bddf@mail.gmail.com> In-Reply-To: <5e81cb500912161826j290a3650o999af91f93d4bddf@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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/msg00099.txt.bz2 =20 > -----Original Message----- > From: gdb-owner@sourceware.org=20 > [mailto:gdb-owner@sourceware.org] On Behalf Of Sean Chen > Sent: Wednesday, December 16, 2009 9:27 PM > To: Marc Khouzam > Cc: Greg Law; Hui Zhu; gdb@sourceware.org > Subject: Re: UndoDB's performance >=20 > On Tue, Dec 15, 2009 at 9:50 PM, Marc Khouzam=20 > wrote: > >> -----Original Message----- > >> From: gdb-owner@sourceware.org > >> [mailto:gdb-owner@sourceware.org] On Behalf Of Greg Law > >> Sent: Tuesday, December 15, 2009 4:12 AM > >> To: Sean Chen > >> Cc: Hui Zhu; gdb@sourceware.org > >> Subject: Re: UndoDB's performance > >> > >> Sean Chen wrote: > >> > On Tue, Dec 15, 2009 at 11:56 AM, Hui Zhu > >> wrote: > >> >> I did some test but its speed close to prec. =A0Some others > >> was better. > >> >> Maybe it have some special performance technology for some code. > >> >> > >> >> Hui > >> >> > >> >> On Tue, Dec 15, 2009 at 10:40, Sean Chen > >> wrote: > >> >>> On Mon, Dec 14, 2009 at 11:07 PM, Hui Zhu > >> wrote: > >> >>>> Try undodb. > >> >>>> > >> >>>> On Mon, Dec 14, 2009 at 21:18, Sean Chen > >> wrote: > >> >>>>> On Mon, Dec 14, 2009 at 7:14 PM, Hui Zhu > >> wrote: > >> >>>>>> gdb-7 reverse debugging accelerator. > >> >>>>>> Regular gdb-7 reverse runs apps =A0 =A0 =A0 =A0 =A040,000x > >> =A0 =A0 =A0 =A0 =A0slower > >> >>>>>> UndoDB+gdb-7 reverse runs apps =A0 =A0 =A0 =A0 =A0 1.7x > >> =A0 slower! > >> >>>>>> > >> >>>>>> > >> >>>>>> Are you really do some try? > >> >>>>>> I suggest you do some test on it. =A0:) > >> >>>>>> > >> >>>>>> Thanks, > >> >>>>>> Hui > >> >>>>>> > >> >>>>>> On Fri, Dec 4, 2009 at 23:34, Sean Chen > >> wrote: > >> >>>>>>> On UndoDb's website, I saw the following ad. > >> >>>>>>> > >> >>>>>>> Regular gdb-7 reverse runs apps 40,000x slower > >> >>>>>>> UndoDB+gdb-7 reverse runs apps 1.7x slower! > >> >>>>>>> > >> >>>>>>> In my experiment, gdb-7 reverse does run apps more > >> than 20,000x > >> >>>>>>> slower. How does UndoDB improve the performance so > >> much without a > >> >>>>>>> simulator and without record? Below is its > >> self-introduction on the > >> >>>>>>> website. UndoDB's "snapshot-and-replay" technique > >> stores periodic > >> >>>>>>> copy-on-write snapshots of the application and only > >> non-deterministic > >> >>>>>>> inputs (system calls, thread-switches, shared memory > >> reads, etc). > >> >>>>>>> > >> >>>>>>> Are there any obvious disadvantages in UndoDB? I > >> tried to search > >> >>>>>>> UndoDB in the archive of the mailing list, however, > >> little discussion > >> >>>>>>> is found. > >> >>>>>>> > >> >>>>>>> -- > >> >>>>>>> Best Regards, > >> >>>>>>> Sean Chen > >> >>>>>>> > >> >>>>> That's UndoDB's ad on its website. > >> >>>>> > >> >>>>> In my experiment, gdb-7 reverse runs apps about=20 > 22,000x slower. > >> >>>>> > >> >>>>> -- > >> >>>>> Best Regards, > >> >>>>> Sean Chen > >> >>>>> > >> >>> I also tried UndoDB, and it is really fast. So I am=20 > sure they are > >> >>> using different strategy. > >> >>> > >> >>> -- > >> >>> Best Regards, > >> >>> Sean Chen > >> >>> > >> > > >> > It might not use process record technique like your design. > >> > > >> > Below is its self-introduction on its website. > >> > UndoDB's "snapshot-and-replay" technique stores periodic > >> copy-on-write > >> > snapshots of the application and only non-deterministic > >> inputs (system > >> > calls, thread-switches, shared memory reads, etc). > >> > > >> > Any comments? > >> > >> Yes, I can confirm that's what we do. =A0We did it that way > >> (and generally > >> tried very hard) to get the best record-time performance. =A0To > >> answer the > >> OP, the downside is replay mode performance, namely stepping > >> backwards, > >> will be worse because you have a lot more work to do. =A0You > >> also need to > >> store the snapshots, although as noted, copy-on-write can > >> mitigate this > >> cost. > > > > In February 09, I had run a couple of tests. =A0Here are the results, > > but keep in mind they are almost a year old and that things might > > have changed since then. > > > > I had a very simple program with a recursive call that=20 > contained a printf. > > I ran the program with and without recording with different depth > > of recursion. =A0No replaying. =A0Two results below. > > > > GDB with *no* recording: 1.35 seconds > > GDB with recording (PRecord): 223 seconds (165 times slower) > > UndoDB: 2.17 seconds (1.6 times slower) > > > > GDB with *no* recording: 0.63 seconds > > GDB with recording (PRecord): 107 seconds (169 times slower) > > UndoDB: 0.74 seconds (1.17 times slower) > > > > As Greg explains, I did notice that in some cases, when actually > > doing back stepping, UndoDB would take a long time to > > perform an operation. =A0Also, going forward again was sometimes > > very slow with UndoDb. > > > > PRecord was better at replaying and had the extremely nice > > feature of allowing you to change memory and resume > > execution. > > > > Marc > > >=20 > Hi Marc, >=20 > I am quite surprise that the performance you logged is 100 times > faster than mine with recording (PRecord). >=20 > I am using the following simple code with gdb 7.0. >=20 > gettimeofday(&tv1, NULL); >=20 > for (i=3D0;i<1000000;i++) { > } >=20 > gettimeofday(&tv2, NULL); >=20 >=20 > In my test, the result is quite different from yours. >=20 > GDB with *no* recording: 2.63 ms > GDB with recording (PRecord): 58554 ms (20000 times slower) >=20 > (gdb) info record insn-number > Record instruction number is 3001052. (Including gettimeofday()) >=20 > I also tried the following recursive function, and the result was > about 10000 times slower. >=20 > void recursive_print(long n) > { > if (n =3D=3D 0) { > printf("recursive_print end\n"); > } else { > recursive_print(n-1); > } > return; > } >=20 > Did you use any optimization? Please do correct me if I make any > mistake. Thanks. My results did seem suspiciously good. Trying things again, I don't get the same results at all. I don't remember my exact orginal test, but I know PRecord had a problem with recursion, maybe that is what skewed the results? Or maybe because I was running on a virtual machine... Or maybe I just made a mistake. Sorry about that. Anyway, I now get GDB with *no* recording: 5.388 ms GDB with recording (PRecord): 31940.035 ms (6000 times slower) > g++ -O0 -g recurse.c > gdb.7.0 a.out GNU gdb (GDB) 7.0 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /local/lmckhou/testing/a.out...done. (gdb) l 1 1 #include 2 #include 3 #define LIMIT 100000 4 5 6 void foo(int i) { 7 if (i =3D=3D 0) return; 8 foo(i-1); 9 } 10 (gdb)=20 11 int main() { 12 timeval tv1, tv2; 13 14 gettimeofday(&tv1, NULL); 15 foo(LIMIT); 16 gettimeofday(&tv2, NULL); 17 18 if (tv1.tv_usec > tv2.tv_usec) { 19 printf("\nTime taken is %d sec %d usec\n", tv2.tv_sec-tv1.t= v_sec+1, tv2.tv_usec+1000000-tv1.tv_usec); 20 } else { (gdb)=20 21 printf("\nTime taken is %d sec %d usec\n", tv2.tv_sec-tv1.t= v_sec, tv2.tv_usec-tv1.tv_usec); 22 } 23 return 0; 24 } (gdb)=20 Line number 25 out of range; recurse.c has 24 lines. (gdb) b 23 Breakpoint 1 at 0x804856f: file recurse.c, line 23. (gdb) start Temporary breakpoint 2 at 0x80484d2: file recurse.c, line 14. Starting program: /local/lmckhou/testing/a.out=20 Temporary breakpoint 2, main () at recurse.c:14 14 gettimeofday(&tv1, NULL); Current language: auto The current source language is "auto; currently c++". (gdb) c Continuing. Time taken is 0 sec 5388 usec Breakpoint 1, main () at recurse.c:23 23 return 0; (gdb) start The program being debugged has been started already. Start it from the beginning? (y or n) y=20 Temporary breakpoint 3 at 0x80484d2: file recurse.c, line 14. Starting program: /local/lmckhou/testing/a.out=20 Temporary breakpoint 3, main () at recurse.c:14 14 gettimeofday(&tv1, NULL); (gdb) record (gdb) set record insn-number-max 10000000 (gdb) c Continuing. Time taken is 31 sec 940035 usec Breakpoint 1, main () at recurse.c:23 23 return 0; (gdb)=20