From: Hui Zhu <teawater@gmail.com>
To: Sean Chen <sean.chen1234@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: UndoDB's performance
Date: Tue, 15 Dec 2009 03:56:00 -0000 [thread overview]
Message-ID: <daef60380912141956y2c5ee83dof731c48de5c4fa3b@mail.gmail.com> (raw)
In-Reply-To: <5e81cb500912141840s389859c2r9c56dd8800adb731@mail.gmail.com>
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
>
next prev parent reply other threads:[~2009-12-15 3:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-04 15:35 Sean Chen
2009-12-14 11:14 ` Hui Zhu
2009-12-14 13:18 ` Sean Chen
2009-12-14 15:08 ` Hui Zhu
2009-12-15 2:40 ` Sean Chen
2009-12-15 3:56 ` Hui Zhu [this message]
2009-12-15 7:26 ` Sean Chen
2009-12-15 9:11 ` Greg Law
2009-12-15 13:50 ` Marc Khouzam
2009-12-17 2:26 ` Sean Chen
2009-12-17 14:41 ` Marc Khouzam
2009-12-17 20:03 ` Michael Snyder
2009-12-18 3:35 ` Hui Zhu
2009-12-18 10:33 ` Sean Chen
2010-01-05 2:47 ` Hui Zhu
2010-01-05 15:34 ` Sean Chen
2010-01-06 3:14 ` Hui Zhu
2010-01-06 8:24 ` Sean Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=daef60380912141956y2c5ee83dof731c48de5c4fa3b@mail.gmail.com \
--to=teawater@gmail.com \
--cc=gdb@sourceware.org \
--cc=sean.chen1234@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox