Re: [Valgrind-users] cachegrind: cache write policy

[Josef W. <Jos...@gm...>]

On Saturday 22 December 2007, Nicholas Nethercote wrote:
> On Sat, 22 Dec 2007, Motaz K. Saad wrote:
>=20
> > I want to know what is the default write policy (write-through or
> > write-back) in cachegrind.
>=20
> Section 3.3.1 of http://www.valgrind.org/docs/phd2004.pdf has the full=20
> details of the simulation.  (As does the code itself, in=20
> cachegrind/cg_sim.c.)

To be more exact: L1 always is write-through. And for L2, which is
write-allocate, a copy of a modified cache line will stay in cache both for
write-through and write-back. Therefore, it does not have any
influence on the state and also not on hit/miss events.
In fact, for cachegrind (and callgrind) it is enough for the cache
state to only emulate read accesses. You can see this in the
simulator code: there is only a cachesim_##L##_doref macro which
does not distinguish between read and write accesses.

In Callgrind, with --simulate-wb=3Dyes, an extended simulator is run
which also simulates the dirty flag for every cache line in the L2.
=46rom this, you get further events such as "L2-miss provoking eviction of
dirty line". For these events, you can specify a larger penalty for
clock cycle estimation (as the bus is more loaded).
However, there are only a few programs where simulation of dirty flags
is worth resulting in more realistic results (the memory bus has to
be fully loaded).

A really nice example here is the "Sieve of Eratosthenes", where the
algorithm is writing again and again the same value for non-primes.
Changing this to write only when the value really changes (ie. by
reading the value beforehand), the program is running twice as fast
(this is only true when the array does not fit into the cache).
Cachegrind does not see any difference in the event counts. However,
with Callgrind with write back simulation you can see the difference...

Josef