<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
</div></div>Will this technology allow us to pinpoint specific accesses that generally have high latency (i.e. generally are cache misses)? This information is useful for programmers, and is also useful as an input to loop unrolling, instruction scheduling, and the like on ooo cores.<br></blockquote><div><br></div><div>Won't hardware performance counter tell you which accesses are delinquent accesses?</div><div>The tools here are trying to provide more information and hopefully some insight of the performance problem.<br></div><div>For example, if we can tell that the working set of an application is slightly bigger than the L3 cache, developers would be able to take the right action to improve the performance.</div><div><br></div><div>We are welcome any suggestions about how the information can be used, or what information should be collected.</div><div><br></div><div>Qin</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
 -Hal<br>
<span class=""><br>
><br>
> *Dead store detection*: this tool identifies dead stores<br>
> (write-after-write patterns with no intervening read) as well as<br>
> redundant stores (writes of the same value already in memory). Xref<br>
> the Deadspy paper from CGO 2012.<br>
><br>
><br>
> *Single-reference*: this tool identifies data cache lines brought in<br>
> but only read once. These could be candidates for non-temporal<br>
> loads.<br>
><br>
><br>
> ====================<br>
> EfficiencySanitizer<br>
> ====================<br>
><br>
><br>
> We are proposing the name EfficiencySanitizer, or "esan" for short,<br>
> to refer to this suite of dynamic instrumentation tools for<br>
> improving program efficiency. As we have a number of different tools<br>
> that share quite a bit of their implementation we plan to consider<br>
> them sub-tools under the EfficiencySanitizer umbrella, rather than<br>
> adding a whole bunch of separate instrumentation and runtime library<br>
> components.<br>
><br>
><br>
> While these tools are not addressing correctness issues like other<br>
> sanitizers, they will be sharing a lot of the existing sanitizer<br>
> runtime library support code. Furthermore, users are already<br>
> familiar with the sanitizer brand, and it seems better to extend<br>
> that concept rather than add some new term.<br>
><br>
><br>
</span><span class="">> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
<br>
--<br>
</span>Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
<span class=""><br>
--<br>
You received this message because you are subscribed to the Google Groups "efficiency-sanitizer" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:efficiency-sanitizer%2Bunsubscribe@google.com">efficiency-sanitizer+unsubscribe@google.com</a>.<br>
To post to this group, send email to <a href="mailto:efficiency-sanitizer@google.com">efficiency-sanitizer@google.com</a>.<br>
</span>To view this discussion on the web visit <a href="https://groups.google.com/a/google.com/d/msgid/efficiency-sanitizer/19928798.1837.1461205693345.JavaMail.hfinkel%40sapling5.localdomain" rel="noreferrer" target="_blank">https://groups.google.com/a/google.com/d/msgid/efficiency-sanitizer/19928798.1837.1461205693345.JavaMail.hfinkel%40sapling5.localdomain</a>.<br>
</blockquote></div><br></div></div>