UndoDB's performance

UndoDB's performance

[Sean Chen]

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

Re: UndoDB's performance

[Hui Zhu]

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
>

Re: UndoDB's performance

[Sean Chen]

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

Re: UndoDB's performance

[Hui Zhu]

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
>

Re: UndoDB's performance

[Sean Chen]

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

Re: UndoDB's performance

[Hui Zhu]

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
>

Re: UndoDB's performance

[Sean Chen]

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?

-- 
Best Regards,
Sean Chen

Re: UndoDB's performance

[Greg Law]

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.

Greg
-- 
Greg Law, Undo Software                       http://undo-software.com/

RE: UndoDB's performance

[Marc Khouzam]

> -----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

Re: UndoDB's performance

[Sean Chen]

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.

-- 
Best Regards,
Sean Chen

RE: UndoDB's performance

[Marc Khouzam]

 

> -----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) 

Re: UndoDB's performance

[Michael Snyder]

Marc Khouzam wrote:
> 
> 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?  

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).

Re: UndoDB's performance

[Hui Zhu]

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.
 It 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.  For example:
Let record_message decode more than one code.  Then we can let
inferior exec more than one insn for each cycle.

Thanks,
Hui


On Fri, Dec 18, 2009 at 04:00, Michael Snyder <msnyder@vmware.com> wrote:
> Marc Khouzam wrote:
>>
>> 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?
>
> 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).
>
>

Re: UndoDB's performance

[Sean Chen]

On Fri, Dec 18, 2009 at 11:35 AM, Hui Zhu <teawater@gmail.com> 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.
>  It 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.  For example:
> Let record_message decode more than one code.  Then we can let
> inferior exec more than one insn for each cycle.
>
> Thanks,
> Hui
>
>
> On Fri, Dec 18, 2009 at 04:00, Michael Snyder <msnyder@vmware.com> wrote:
>> Marc Khouzam wrote:
>>>
>>> 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?
>>
>> 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

Re: UndoDB's performance

[Hui Zhu]

The idea is not bad.  If you can do something is better.  :)

Thanks,
Hui

On Fri, Dec 18, 2009 at 18:33, Sean Chen <sean.chen1234@gmail.com> wrote:
> On Fri, Dec 18, 2009 at 11:35 AM, Hui Zhu <teawater@gmail.com> 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.
>>  It 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.  For example:
>> Let record_message decode more than one code.  Then we can let
>> inferior exec more than one insn for each cycle.
>>
>> Thanks,
>> Hui
>>
>>
>> On Fri, Dec 18, 2009 at 04:00, Michael Snyder <msnyder@vmware.com> wrote:
>>> Marc Khouzam wrote:
>>>>
>>>> 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?
>>>
>>> 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
>

Re: UndoDB's performance

[Sean Chen]

> The idea is not bad.  If you can do something is better.  :)
Of course I will try in case the idea is mature enough. And your
experience is very important. Do you know the execution time
(proportion) of each step? You know, it highly depends on the
proportion of these three steps.
1. parse the instruction
2. store the delta status
3. single step the instruction

-- 
Best Regards,
Sean Chen

Re: UndoDB's performance

[Hui Zhu]

I still didn't get this data.  Maybe you can help us with it.  :)

Thanks,
Hui

On Tue, Jan 5, 2010 at 23:34, Sean Chen <sean.chen1234@gmail.com> wrote:
>> The idea is not bad.  If you can do something is better.  :)
> Of course I will try in case the idea is mature enough. And your
> experience is very important. Do you know the execution time
> (proportion) of each step? You know, it highly depends on the
> proportion of these three steps.
> 1. parse the instruction
> 2. store the delta status
> 3. single step the instruction
>
> --
> Best Regards,
> Sean Chen
>

Re: UndoDB's performance

[Sean Chen]

> I still didn't get this data.  Maybe you can help us with it.  :)

I will keep this in mind. :)

-- 
Best Regards,
Sean Chen