[llvm-dev] RFC: EfficiencySanitizer

Thu Apr 21 11:20:40 PDT 2016

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>