This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Faster compilation speed: cache behavior
- From: kaih at khms dot westfalen dot de (Kai Henningsen)
- To: gcc at gcc dot gnu dot org
- Date: 22 Aug 2002 08:47:00 +0200
- Subject: Re: Faster compilation speed: cache behavior
- Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
- Organization: Organisation? Me?! Are you kidding?
- References: <8VJTeokHw-B@khms.westfalen.de> <B79263D9-B560-11D6-B144-000393941EE6@apple.com>
mrs@apple.com (Mike Stump) wrote on 21.08.02 in <B79263D9-B560-11D6-B144-000393941EE6@apple.com>:
> On Tuesday, August 20, 2002, at 11:40 PM, Kai Henningsen wrote:
> > mrs@apple.com (Mike Stump) wrote on 20.08.02 in
> > <CE111330-B490-11D6-90A6-000393941EE6@apple.com>:
> >
> >> On Tuesday, August 20, 2002, at 03:45 PM, Geoff Keating wrote:
> >>> Does Apple's memset use dcbz? I'm curious why memset should cause
> >>> any
> >>> cache misses at all.
> >>
> >> The symbols mentioned are just one possible value of the pc within the
> >> millisecond (by default) when the sample was taken. The sample
> >
> > Uh, I thought they were the exact instruction that caused the cache
> > miss,
> > and this particular profile was *not* based on timed samples?!
>
> I am very new to all the counters and their semantics and what all the
> numbers mean. However, from my limited understanding, I don't believe
> this is the case. Was your understanding obtained by reading the chip
> docs about the counters? By experimenting with them heavily?
By reading what Matt wrote about it, at the start of the thread. He
claimed that he first obtained a list of the instructions causing cache
misses, and then figured out where they were belonged.
I have no idea if that is true, but when what you claim and what he claims
is so drastically different, confusion is only to be expected.
MfG Kai