This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: UndoDB's performance
- From: Hui Zhu <teawater at gmail dot com>
- To: Sean Chen <sean dot chen1234 at gmail dot com>
- Cc: Michael Snyder <msnyder at vmware dot com>, Marc Khouzam <marc dot khouzam at ericsson dot com>, Greg Law <glaw at undo-software dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Tue, 5 Jan 2010 10:47:25 +0800
- Subject: Re: UndoDB's performance
- References: <5e81cb500912040734u5ce67afdpd6a2d0e63173f908@mail.gmail.com> <daef60380912141956y2c5ee83dof731c48de5c4fa3b@mail.gmail.com> <5e81cb500912142326t1bd545ek9180661d8bac10fe@mail.gmail.com> <4B2752C6.4050804@undo-software.com> <F7CE05678329534C957159168FA70DEC515C66CA56@EUSAACMS0703.eamcs.ericsson.se> <5e81cb500912161826j290a3650o999af91f93d4bddf@mail.gmail.com> <F7CE05678329534C957159168FA70DEC515C6AD2F1@EUSAACMS0703.eamcs.ericsson.se> <4B2A8DE9.5050200@vmware.com> <daef60380912171935w721cf97ay95e95d09b21850c2@mail.gmail.com> <5e81cb500912180233w9c64972wb1fb60d76584ed0b@mail.gmail.com>
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
>