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>
----- 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 1:20:40 PM > Subject: Re: [llvm-dev] RFC: EfficiencySanitizer> 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.Interesting, thanks! That sounds potentially useful. -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 >-- 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/7c107c9f/attachment.html>
On Thu, Apr 21, 2016 at 11:24 AM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> 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 1:20:40 PM > *Subject: *Re: [llvm-dev] RFC: EfficiencySanitizer > > > > 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. > > Interesting, thanks! That sounds potentially useful. >The problem with using HW performance counters for this kind of problem is that the reported 'cache miss hotspots' are sometimes the symptom, not the root cause -- the reported accesses are likely to be innocent and are the victims of the real problems elsewhere. For instance a large write that pollutes the cache if not marked as non-temporal. Such issues needs to be looked at globally with collective evidence. David> > -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 >> > > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160421/2b8f59ab/attachment-0001.html>