[llvm-dev] RFC: EfficiencySanitizer

Thu Apr 21 12:01:50 PDT 2016

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>