Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA] Use data cache for stack accesses
Date: Thu, 27 Aug 2009 03:11:00 -0000	[thread overview]
Message-ID: <e394668d0908262011r50869ba7i2614ae06440408d@mail.gmail.com> (raw)
In-Reply-To: <e394668d0908261732y26164fb0t7696869b96794abe@mail.gmail.com>

On Wed, Aug 26, 2009 at 5:32 PM, Doug Evans<dje@google.com> wrote:
> On Wed, Aug 26, 2009 at 1:08 PM, Pedro Alves<pedro@codesourcery.com> wrote:
>>> > Did you post number showing off the improvements from
>>> > having the cache on?  E.g., when doing foo, with cache off,
>>> > I get NNN memory reads, while with cache off, we get only
>>> > nnn reads.  I'd be curious to have some backing behind
>>> > "This improves remote performance significantly".
>>>
>>> For a typical gdb/gdbserver connection here a backtrace of 256 levels
>>> went from 48 seconds (average over 6 tries) to 4 seconds (average over
>>> 6 tries).
>>
>> Nice!  Were all those single runs started from cold cache, or
>> are you starting from a cold cache and issuing 6 backtraces in
>> a row?  I mean, how sparse were those 6 tries?  Shall one
>> read that as 48,48,48,48,48,48 vs 20,1,1,1,1,1 (some improvement
>> due to chunking, and large improvement due to caching in following
>> repeats of the command); or 48,48,48,48,48,48 vs 4,4,4,4,4,4 (large
>> improvement due to chunking --- caching not actually measured)?
>
> The cache was always flushed between backtraces, so that's
> 48, 48. ..., 48 vs 4, 4, ..., 4.
>
> Backtraces win from both chunking and caching.
> Even in one backtrace gdb will often fetch the same value multiple times.
> I haven't computed the relative win.

Besides, the chunking doesn't really work without the caching. :-)


  reply	other threads:[~2009-08-27  3:11 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-08 20:49 Jacob Potter
2009-07-08 20:51 ` Pedro Alves
2009-07-08 20:58   ` Pedro Alves
2009-07-08 23:46   ` Daniel Jacobowitz
2009-07-09  3:06     ` Pedro Alves
2009-07-10  9:34       ` Pedro Alves
2009-07-10  8:45     ` Jacob Potter
2009-07-10 14:19       ` Pedro Alves
2009-07-13 19:25         ` Jacob Potter
2009-08-21  6:25   ` Doug Evans
2009-08-25  3:00     ` Doug Evans
2009-08-25 18:55       ` Pedro Alves
2009-08-26 16:36         ` Doug Evans
2009-08-26 22:45           ` Pedro Alves
2009-08-27  0:46             ` Doug Evans
2009-08-27  3:11               ` Doug Evans [this message]
2009-08-29  5:16             ` Doug Evans
2009-08-29 18:28               ` Doug Evans
2009-08-29 20:25               ` Pedro Alves
2009-09-02 20:43       ` Tom Tromey
2009-09-03 15:38         ` Doug Evans
2009-09-03 19:38           ` Tom Tromey
2009-09-03 19:45           ` Daniel Jacobowitz
2009-07-09 12:20 ` Eli Zaretskii

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=e394668d0908262011r50869ba7i2614ae06440408d@mail.gmail.com \
    --to=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.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