This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Faster compilation speed: cache behavior



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?!

AFAIK, on the G3 and G4 it's not possible to get alerted to the exact address
of the insn that generated a performance monitor event; you can only get the
address of the last machine instruction that completed before the event was
generated (from the (U)SIAR register).  This is much better than a millisecond
resolution, but not exact; the insn that led to the triggering of the event
is probably still in the completion queue (insns are completed in
program order
on powerpc).

Or maybe Apple's tool uses some different mechanism; in that case, please
ignore me.

Btw, even if memset() uses dcbz, dcbz only clears whole cache blocks, so you
need to do normal stores for the "corner cases", which can generate L2 misses.


Segher



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]