[llvm-dev] RFC: EfficiencySanitizer

[Hal Finkel via llvm-dev]

----- 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>