> > > 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. >Won't hardware performance counter tell you which accesses are delinquent accesses? The tools here are trying to provide more information and hopefully some insight of the performance problem. 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. We are welcome any suggestions about how the information can be used, or what information should be collected. Qin> > -Hal > > > > > *Dead store detection*: this tool identifies dead stores > > (write-after-write patterns with no intervening read) as well as > > redundant stores (writes of the same value already in memory). Xref > > the Deadspy paper from CGO 2012. > > > > > > *Single-reference*: this tool identifies data cache lines brought in > > but only read once. These could be candidates for non-temporal > > loads. > > > > > > ===================> > EfficiencySanitizer > > ===================> > > > > > We are proposing the name EfficiencySanitizer, or "esan" for short, > > to refer to this suite of dynamic instrumentation tools for > > improving program efficiency. As we have a number of different tools > > that share quite a bit of their implementation we plan to consider > > them sub-tools under the EfficiencySanitizer umbrella, rather than > > adding a whole bunch of separate instrumentation and runtime library > > components. > > > > > > While these tools are not addressing correctness issues like other > > sanitizers, they will be sharing a lot of the existing sanitizer > > runtime library support code. Furthermore, users are already > > familiar with the sanitizer brand, and it seems better to extend > > that concept rather than add some new term. > > > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > > -- > You received this message because you are subscribed to the Google Groups > "efficiency-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to efficiency-sanitizer+unsubscribe at google.com. > To post to this group, send email to efficiency-sanitizer at google.com. > To view this discussion on the web visit > https://groups.google.com/a/google.com/d/msgid/efficiency-sanitizer/19928798.1837.1461205693345.JavaMail.hfinkel%40sapling5.localdomain > . >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160421/55f919dc/attachment.html>
----- Original Message -----> From: "Qin Zhao" <zhaoqin at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Derek Bruening" <bruening at google.com>, > efficiency-sanitizer at google.com, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Thursday, April 21, 2016 12:48:20 PM > Subject: Re: [llvm-dev] RFC: EfficiencySanitizer> > 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. >> Won't hardware performance counter tell you which accesses are > delinquent accesses?Yes, for the particular system on which you're running. The question is, as the (effective) cache size changes (either because you're running more threads per core, socket, etc. or as you run across different architectures), can you say where the cache-miss hot-spots will be? -Hal> The tools here are trying to provide more information and hopefully > some insight of the performance problem.> 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.> We are welcome any suggestions about how the information can be used, > or what information should be collected.> Qin> > -Hal >> > > > > > > *Dead store detection*: this tool identifies dead stores > > > > (write-after-write patterns with no intervening read) as well as > > > > redundant stores (writes of the same value already in memory). > > > Xref > > > > the Deadspy paper from CGO 2012. > > > > > > > > > > > > *Single-reference*: this tool identifies data cache lines brought > > > in > > > > but only read once. These could be candidates for non-temporal > > > > loads. > > > > > > > > > > > > ===================> > > > EfficiencySanitizer > > > > ===================> > > > > > > > > > > > We are proposing the name EfficiencySanitizer, or "esan" for > > > short, > > > > to refer to this suite of dynamic instrumentation tools for > > > > improving program efficiency. As we have a number of different > > > tools > > > > that share quite a bit of their implementation we plan to > > > consider > > > > them sub-tools under the EfficiencySanitizer umbrella, rather > > > than > > > > adding a whole bunch of separate instrumentation and runtime > > > library > > > > components. > > > > > > > > > > > > While these tools are not addressing correctness issues like > > > other > > > > sanitizers, they will be sharing a lot of the existing sanitizer > > > > runtime library support code. Furthermore, users are already > > > > familiar with the sanitizer brand, and it seems better to extend > > > > that concept rather than add some new term. > > > > > > > > > > > > _______________________________________________ > > > > LLVM Developers mailing list > > > > llvm-dev at lists.llvm.org > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > >> > -- > > > Hal Finkel > > > Assistant Computational Scientist > > > Leadership Computing Facility > > > Argonne National Laboratory >> > -- > > > You received this message because you are subscribed to the Google > > Groups "efficiency-sanitizer" group. > > > To unsubscribe from this group and stop receiving emails from it, > > send an email to efficiency-sanitizer+unsubscribe at google.com . > > > To post to this group, send email to > > efficiency-sanitizer at google.com > > . > > > To view this discussion on the web visit > > https://groups.google.com/a/google.com/d/msgid/efficiency-sanitizer/19928798.1837.1461205693345.JavaMail.hfinkel%40sapling5.localdomain > > . >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160421/25315a3c/attachment.html>
On Thu, Apr 21, 2016 at 1:57 PM, Hal Finkel <hfinkel at anl.gov> wrote:> > > ------------------------------ > > *From: *"Qin Zhao" <zhaoqin at google.com> > *To: *"Hal Finkel" <hfinkel at anl.gov> > *Cc: *"Derek Bruening" <bruening at google.com>, > efficiency-sanitizer at google.com, "llvm-dev" <llvm-dev at lists.llvm.org> > *Sent: *Thursday, April 21, 2016 12:48:20 PM > *Subject: *Re: [llvm-dev] RFC: EfficiencySanitizer > > >> 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. >> > > Won't hardware performance counter tell you which accesses are delinquent > accesses? > > Yes, for the particular system on which you're running. The question is, > as the (effective) cache size changes (either because you're running more > threads per core, socket, etc. or as you run across different > architectures), can you say where the cache-miss hot-spots will be? > > -Hal > >There are many reasons that may cause the cache misses. Since we are not doing a full cache simulation, we won't be to report the cache-miss for all cases. However, it is possible in certain cases. Because we could keep up to 8 snapshot of the working set (xref the working set tool RFC), we could easily identify the memory reference that touches a cache line that were not touched in the previous snapshot. Such references has a high chance to cause cache misses. The tools here are trying to provide more information and hopefully some> insight of the performance problem. > 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. > > We are welcome any suggestions about how the information can be used, or > what information should be collected. > > Qin > > >> >> -Hal >> >> > >> > *Dead store detection*: this tool identifies dead stores >> > (write-after-write patterns with no intervening read) as well as >> > redundant stores (writes of the same value already in memory). Xref >> > the Deadspy paper from CGO 2012. >> > >> > >> > *Single-reference*: this tool identifies data cache lines brought in >> > but only read once. These could be candidates for non-temporal >> > loads. >> > >> > >> > ===================>> > EfficiencySanitizer >> > ===================>> > >> > >> > We are proposing the name EfficiencySanitizer, or "esan" for short, >> > to refer to this suite of dynamic instrumentation tools for >> > improving program efficiency. As we have a number of different tools >> > that share quite a bit of their implementation we plan to consider >> > them sub-tools under the EfficiencySanitizer umbrella, rather than >> > adding a whole bunch of separate instrumentation and runtime library >> > components. >> > >> > >> > While these tools are not addressing correctness issues like other >> > sanitizers, they will be sharing a lot of the existing sanitizer >> > runtime library support code. Furthermore, users are already >> > familiar with the sanitizer brand, and it seems better to extend >> > that concept rather than add some new term. >> > >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >> >> -- >> Hal Finkel >> Assistant Computational Scientist >> Leadership Computing Facility >> Argonne National Laboratory >> >> -- >> You received this message because you are subscribed to the Google Groups >> "efficiency-sanitizer" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to efficiency-sanitizer+unsubscribe at google.com. >> To post to this group, send email to efficiency-sanitizer at google.com. >> To view this discussion on the web visit >> https://groups.google.com/a/google.com/d/msgid/efficiency-sanitizer/19928798.1837.1461205693345.JavaMail.hfinkel%40sapling5.localdomain >> . >> > > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160421/92ef625e/attachment.html>