<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 4/18/2016 1:02 PM, Derek Bruening wrote:<br>
<blockquote
cite="mid:CAO1ikSY=MNBvt2dsnosd-vHOYzU2u-YXBmFLAu2+MUr7RCjuPw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Apr 18, 2016 at 1:36 PM,
Craig, Ben via llvm-dev <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class=""></span></div>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<blockquote type="cite">
<div dir="ltr">
<div>*Working set measurement*: this tool measures
the data working set size of an application at
each snapshot during execution. It can help to
understand phased behavior as well as providing
basic direction for further effort by the
developer: e.g., knowing whether the working set
is close to fitting in current L3 caches or is
many times larger can help determine where to
spend effort.</div>
</div>
</blockquote>
</span> I think my questions here are basically the
reverse of my prior questions. I can imagine the
presentation ( a graph with time on the X axis, working
set measurement on the Y axis, with some markers
highlighting key execution points). I'm not sure how
the data collection works though, or even really what is
being measured. Are you planning on counting the number
of data bytes / data cache lines used during each time
period? For the purposes of this tool, when is data
brought into the working set and when is data evicted
from the working set?<br>
</div>
</blockquote>
<div><br>
</div>
<div>The tool records which data cache lines were touched at
least once during a snapshot (basically just setting a
shadow memory bit for each load/store). The metadata is
cleared after each snapshot is recorded so that the next
snapshot starts with a blank slate. Snapshots can be
combined via logical or as the execution time grows to
adaptively handle varying total execution time.</div>
</div>
</div>
</div>
</blockquote>
So I guess a visualization of that information could show how much
new memory was referenced per snapshot, how much was the same from a
prior snapshot, and how much was "dropped". Neat.<br>
<br>
<br>
Some other things that might be useful to look for (unrelated to the
Working set measurement tool):<br>
* Missed restrict opportunities<br>
With shadow memory, you should be able to track whether there is
aliasing in practice for a given execution, and whether annotating
with restrict would reduce the number of loads and stores.<br>
<br>
* Missed vectorization opportunities<br>
I'm not exactly sure how you could annotate on this front, but this
blog post (
<a class="moz-txt-link-freetext" href="http://blog.llvm.org/2014/11/loop-vectorization-diagnostics-and.html">http://blog.llvm.org/2014/11/loop-vectorization-diagnostics-and.html</a>
) describes where some diagnostics are already present. If you can
also determine whether those optimizations would be valuable through
instrumentation, then it could be valuable to report it.<br>
<br>
<pre class="moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
</pre>
</body>
</html>