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: gcc cache misses [was: Re: OT: How is memory latency importanton AMD64 box while compiling large C/C++ sources]

From: Nicholas Nethercote <njn at cs dot utexas dot edu>
To: Karel Gardas <kgardas at objectsecurity dot com>
Cc: Mike Stump <mrs at apple dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>
Date: Tue, 12 Apr 2005 19:12:37 -0500 (CDT)
Subject: Re: gcc cache misses [was: Re: OT: How is memory latency importanton AMD64 box while compiling large C/C++ sources]
References: <Pine.LNX.4.43.0504122146190.833-100000@thinkpad.gardas.net>

On Tue, 12 Apr 2005, Karel Gardas wrote:

cachegrind can also be used to estimate the number (though, not sure
how accurate it is, possibly not very).  I use Shark to actually get
the real number.


Perhaps it's possible that cachegrind is wrong or cache misses differ from
platform to platform, but I would tell that I get very good numbers for
gcc running on x86 platform:

In my experience Cachegrind can give pretty good numbers for L1 misses, espcially D1, but the L2 misses tend to vary more. I saw this with comparisons against the real numbers reported by the performance counters on an Athlon. However, Cachegrind certainly makes a number of approximations (see section 3.3.7 of http://www.valgrind.org/docs/phd2004.pdf) and so you shouldn't trust it too much. It should give reasonable numbers though.

N

References:
- gcc cache misses [was: Re: OT: How is memory latency important onAMD64 box while compiling large C/C++ sources]
  - From: Karel Gardas

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