This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: UndoDB's performance


 

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [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
> 
> On Tue, Dec 15, 2009 at 9:50 PM, Marc Khouzam 
> <marc.khouzam@ericsson.com> 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
> >> <teawater@gmail.com> wrote:
> >> >> I did some test but its speed close to prec. ?Some others
> >> was better.
> >> >> Maybe it have some special performance technology for some code.
> >> >>
> >> >> Hui
> >> >>
> >> >> On Tue, Dec 15, 2009 at 10:40, Sean Chen
> >> <sean.chen1234@gmail.com> wrote:
> >> >>> On Mon, Dec 14, 2009 at 11:07 PM, Hui Zhu
> >> <teawater@gmail.com> wrote:
> >> >>>> Try undodb.
> >> >>>>
> >> >>>> On Mon, Dec 14, 2009 at 21:18, Sean Chen
> >> <sean.chen1234@gmail.com> wrote:
> >> >>>>> On Mon, Dec 14, 2009 at 7:14 PM, Hui Zhu
> >> <teawater@gmail.com> wrote:
> >> >>>>>> gdb-7 reverse debugging accelerator.
> >> >>>>>> Regular gdb-7 reverse runs apps ? ? ? ? ?40,000x
> >> ? ? ? ? ?slower
> >> >>>>>> UndoDB+gdb-7 reverse runs apps ? ? ? ? ? 1.7x
> >> ? slower!
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Are you really do some try?
> >> >>>>>> I suggest you do some test on it. ?:)
> >> >>>>>>
> >> >>>>>> Thanks,
> >> >>>>>> Hui
> >> >>>>>>
> >> >>>>>> On Fri, Dec 4, 2009 at 23:34, Sean Chen
> >> <sean.chen1234@gmail.com> 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 
> 22,000x slower.
> >> >>>>>
> >> >>>>> --
> >> >>>>> Best Regards,
> >> >>>>> Sean Chen
> >> >>>>>
> >> >>> I also tried UndoDB, and it is really fast. So I am 
> 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. ?We did it that way
> >> (and generally
> >> tried very hard) to get the best record-time performance. ?To
> >> answer the
> >> OP, the downside is replay mode performance, namely stepping
> >> backwards,
> >> will be worse because you have a lot more work to do. ?You
> >> 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. ?Here 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 
> contained a printf.
> > I ran the program with and without recording with different depth
> > of recursion. ?No replaying. ?Two 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. ?Also, 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
> >
> 
> Hi Marc,
> 
> I am quite surprise that the performance you logged is 100 times
> faster than mine with recording (PRecord).
> 
> I am using the following simple code with gdb 7.0.
> 
>   gettimeofday(&tv1, NULL);
> 
>   for (i=0;i<1000000;i++) {
>   }
> 
>   gettimeofday(&tv2, NULL);
> 
> 
> In my test, the result is quite different from yours.
> 
> GDB with *no* recording: 2.63 ms
> GDB with recording (PRecord): 58554 ms (20000 times slower)
> 
> (gdb) info record insn-number
> Record instruction number is 3001052. (Including gettimeofday())
> 
> I also tried the following recursive function, and the result was
> about 10000 times slower.
> 
> void recursive_print(long n)
> {
>   if (n == 0) {
>     printf("recursive_print end\n");
>   } else {
>     recursive_print(n-1);
>   }
>   return;
> }
> 
> 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 <http://gnu.org/licenses/gpl.html>
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:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /local/lmckhou/testing/a.out...done.
(gdb) l 1
1       #include <stdio.h>
2       #include <sys/time.h>
3       #define LIMIT 100000
4
5
6       void foo(int i) {
7           if (i == 0) return;
8           foo(i-1);
9       }
10
(gdb) 
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.tv_sec+1, tv2.tv_usec+1000000-tv1.tv_usec);
20          } else {
(gdb) 
21              printf("\nTime taken is %d sec %d usec\n", tv2.tv_sec-tv1.tv_sec, tv2.tv_usec-tv1.tv_usec);
22          }
23          return 0;
24      }
(gdb) 
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 

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 
Temporary breakpoint 3 at 0x80484d2: file recurse.c, line 14.
Starting program: /local/lmckhou/testing/a.out 

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) 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]