<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 20, 2016 at 7:58 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 17 April 2016 at 22:46, Derek Bruening via llvm-dev<br><span class="">> Studying instruction cache behavior with compiler<br>
> instrumentation can be challenging, however, so we plan to at least<br>
> initially focus on data performance.<br>
<br>
</span>I'm interested in how you're going to do this without kernel profiling<br>
probes, like perf.<br>
<br>
Or is the point here introducing syscalls in the right places instead<br>
of randomly profiled? Wouldn't that bias your results?<br></blockquote><div><br></div><div>I'm not sure I understand the question: are you asking whether not gathering data on time spent in the kernel is an issue?  Or you're asking how to measure aspects of performance without using sampling or hardware performance counters?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Many of our planned tools target specific performance issues with data<br>
> accesses.  They employ the technique of *shadow memory* to store metadata<br>
> about application data references, using the compiler to instrument loads<br>
> and stores with code to update the shadow memory.<br>
<br>
</span>Is it just counting the number of reads/writes? Or are you going to<br>
add how many of those accesses were hit by a cache miss?<br></blockquote><div><br></div><div>It varies by tool.  The brief descriptions in the original email hopefully shed some light; we are also sending separate RFC's for each tool (working set was already sent).  The cache frag tool is basically just counting, yes.  There is no cache miss information here: we are not using hardware perf counters nor running a software cache simulation.  We are measuring particular aspects of application behavior that tend to affect performance, often abstracted away from the precise microarchitecture you're running on.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> *Cache fragmentation*: this tool gather data structure field hotness<br>
> information, looking for data layout optimization opportunities by grouping<br>
> hot fields together to avoid data cache fragmentation.  Future enhancements<br>
> may add field affinity information if it can be computed with low enough<br>
> overhead.<br>
<br>
</span>Would be also good to have temporal information, so that you can<br>
correlate data access that occurs, for example, inside the same loop /<br>
basic block, or in sequence in the common CFG flow. This could lead to<br>
change in allocation patterns (heap, BSS).<br></blockquote><div><br></div><div>Agreed, we have thought about adding temporal information, though it would cost more and we have not flushed out the details.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> *Working set measurement*: this tool measures the data working set size of<br>
> an application at each snapshot during execution.  It can help to understand<br>
> phased behavior as well as providing basic direction for further effort by<br>
> the developer: e.g., knowing whether the working set is close to fitting in<br>
> current L3 caches or is many times larger can help determine where to spend<br>
> effort.<br>
<br>
</span>This is interesting, but most useful when your dataset changes size<br>
over different runs. This is similar to running the program under perf<br>
for different workloads, and I'm not sure how you're going to get that<br>
in a single run. It also comes with the additional problem that cache<br>
sizes are not always advertised, so you might have an additional tool<br>
to guess the sizes based on increasing the size of data blocks and<br>
finding steps on the data access graph.<br></blockquote><div><br></div><div>This tool is relatively agnostic of the precise details of the caches beyond having its granularity based on the cache line size it assumes (64 bytes, can be parametrized).</div><div><br></div></div></div></div>