|
From: <sv...@va...> - 2012-10-07 21:03:34
|
florian 2012-10-07 22:03:27 +0100 (Sun, 07 Oct 2012)
New Revision: 13030
Log:
Use last-level cache for simulation. Even if there are more than
3 cache levels. Update documentation.
Modified files:
trunk/cachegrind/cg-arch.c
trunk/cachegrind/docs/cg-manual.xml
Modified: trunk/cachegrind/cg-arch.c (+0 -2)
===================================================================
--- trunk/cachegrind/cg-arch.c 2012-10-07 21:27:38 +01:00 (rev 13029)
+++ trunk/cachegrind/cg-arch.c 2012-10-07 22:03:27 +01:00 (rev 13030)
@@ -302,8 +302,6 @@
// Extract what we need
i1 = locate_cache(ci, INSN_CACHE, 1);
d1 = locate_cache(ci, DATA_CACHE, 1);
- // FIXME: needs clarification for num_levels > 3 see also warning below
- // FIXME: whether it needs adjustment
ll = locate_cache(ci, UNIFIED_CACHE, ci->num_levels);
if (ll && ci->num_levels > 2) {
Modified: trunk/cachegrind/docs/cg-manual.xml (+3 -3)
===================================================================
--- trunk/cachegrind/docs/cg-manual.xml 2012-10-07 21:27:38 +01:00 (rev 13029)
+++ trunk/cachegrind/docs/cg-manual.xml 2012-10-07 22:03:27 +01:00 (rev 13030)
@@ -20,10 +20,10 @@
unified second-level cache (L2). This exactly matches the configuration of
many modern machines.</para>
-<para>However, some modern machines have three levels of cache. For these
+<para>However, some modern machines have three or four levels of cache. For these
machines (in the cases where Cachegrind can auto-detect the cache
-configuration) Cachegrind simulates the first-level and third-level caches.
-The reason for this choice is that the L3 cache has the most influence on
+configuration) Cachegrind simulates the first-level and last-level caches.
+The reason for this choice is that the last-level cache has the most influence on
runtime, as it masks accesses to main memory. Furthermore, the L1 caches
often have low associativity, so simulating them can detect cases where the
code interacts badly with this cache (eg. traversing a matrix column-wise
|