From: Sean Chen <sean.chen1234@gmail.com>
To: Hui Zhu <teawater@gmail.com>
Cc: Michael Snyder <msnyder@vmware.com>,
Marc Khouzam <marc.khouzam@ericsson.com>,
Greg Law <glaw@undo-software.com>,
"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: UndoDB's performance
Date: Fri, 18 Dec 2009 10:33:00 -0000 [thread overview]
Message-ID: <5e81cb500912180233w9c64972wb1fb60d76584ed0b@mail.gmail.com> (raw)
In-Reply-To: <daef60380912171935w721cf97ay95e95d09b21850c2@mail.gmail.com>
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
next prev parent reply other threads:[~2009-12-18 10:33 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
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 [this message]
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=5e81cb500912180233w9c64972wb1fb60d76584ed0b@mail.gmail.com \
--to=sean.chen1234@gmail.com \
--cc=gdb@sourceware.org \
--cc=glaw@undo-software.com \
--cc=marc.khouzam@ericsson.com \
--cc=msnyder@vmware.com \
--cc=teawater@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