We have talked at length about caches in this chapter, but is there a way to see how our application is performing in this sense? There actually is. It's called Cachegrind, and it's part of Valgrind. It's used in the same way as Callgrind, with cargo profiler. In the case of the same preceding application, the cargo profiler failed to parse Cachegrind's response, so I had to run Valgrind directly, as you can see in the following screenshot:

This was my second or third run, so some information might have already been cached. But still, as you can see, 2.1% of the first-level data cache missed, which is not so bad, given that the second-level cache had that data most of the time (it only missed 0.1% of the time).

Instruction data was fetched properly at the level 1 cache almost all the time, except for 0.04% of the time. There was almost no miss at level 2. Cachegrind can also give us more valuable information with some flags though.

Using --branch-sim=yes as an argument, we can see how the branch prediction worked:

As we can see, 3.3% of the branches were not predicted properly. This means that an interesting improvement could be done if branches were more predictable, or if some loops were unrolled, as we saw previously.

This, by itself, tells us nothing about where we could improve our code. But using the tool creates a cachegrind.out file in the current directory. This file can be used by another tool, cg_anotate, that will show improved stats. Running it, you will see the various stats on a per-function basis, where you can see which functions are giving the cache more trouble, and go there to try to fix them.

In the case of SUPER, it seems that the resource decompress is giving more cache misses. It might make sense, though, since it's reading new data from a file and reading that data almost all the time from memory for the first time. But maybe we can check those functions and try to improve the fetching, by using buffers, for example, if they are not being used.