search for: bruening

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

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

Hi everyone, I have a code style question: should full test programs (.c,.cpp files) use the documented CamelCase from http://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly or instead use lower_with_underscores as I've been told the .ll lit test files should use? I see both in existing files, and in particular for projects/compiler-rt I cannot

On Tue, Apr 19, 2016 at 10:18 AM Filipe Cabecinhas via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sun, Apr 17, 2016 at 10:46 PM, Derek Bruening via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > TL;DR: We plan to build a suite of compiler-based dynamic instrumentation > > tools for analyzing targeted performance problems. These tools will all > > live under a new "EfficiencySanitizer" (or "esa...

Please reference the prior RFC on EfficiencySanitizer. This is one of the performance analysis tools we would like to build under the EfficiencySanitizer umbrella. ==================== Motivation ==================== Knowing the working set size at periodic points during a given application's execution helps to understand its cache behavior, how its behavior changes over time, how its

On Mon, Apr 18, 2016 at 1:36 PM, Craig, Ben via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 4/17/2016 4:46 PM, Derek Bruening via llvm-dev wrote: > > *Cache fragmentation*: this tool gather data structure field hotness > information, looking for data layout optimization opportunities by grouping > hot fields together to avoid data cache fragmentation. Future enhancements > may add field affinity informatio...

...local), possible compiler optimizations (static analysis can prove that some accesses always read initialized memory), and a fast start-up. Our preliminary measurements show 3x-4x slowdown; compare it to Memchecks's 20x and DrMemory's 10x. (See http://groups.csail.mit.edu/commit/papers/2011/bruening-cgo11-drmemory.pdf for those numbers). But this brings the major issue as well: msan needs to see all program events, including system calls and reads/writes in system libraries, so we either need to compile *everything* with msan or use a binary translation component to instrument pre-built librar...

TL;DR: We plan to build a suite of compiler-based dynamic instrumentation tools for analyzing targeted performance problems. These tools will all live under a new "EfficiencySanitizer" (or "esan") sanitizer umbrella, as they will share significant portions of their implementations. ==================== Motivation ==================== Our goal is to build a suite of dynamic

...izations (static analysis can prove that some > accesses always read initialized memory), > and a fast start-up. > Our preliminary measurements show 3x-4x slowdown; compare it to > Memchecks's 20x and DrMemory's 10x. > (See > http://groups.csail.mit.edu/commit/papers/2011/bruening-cgo11-drmemory.pdf for > those numbers). > But this brings the major issue as well: msan needs to see all program > events, including system calls and reads/writes in system libraries, > so we either need to compile *everything* with msan or use a binary > translation component to in...

I'm running FC5 (2.6.15-1.2054_FC5smp) and Dovecot dovecot-1.0-0.beta8.2.fc5 with Thunderbird 2.0.0.16. I set up imap (dovecot) so I can access my mail locally or remotely. It seems to take a very long time (minutes sometimes) for an Email to be retrieved after I select it in the folder list and/or in the Email list locally or remotely. I've traced the imap process and found it doing a

On Wed, Apr 20, 2016 at 2:48 AM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Tue, Apr 19, 2016 at 10:44 PM, Derek Bruening via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Please reference the prior RFC on EfficiencySanitizer. This is one of >> the performance analysis tools we would like to build under the >> EfficiencySanitizer umbrella. >> >> ==================== &g...

Thanks for the comment and suggestions. That's a great idea! We actually thought about using each heap object with its type information for more accurate data, and it is definitely in our future plan. However, there are challenges to do so. For example, getting correct type information for each heap object might not be easy, especially for C programs. An application can even use a custom

Have you consider naming it `performance sanitizer` instead? I believe that it would be easier to misheard esan with asan, and psan would solve it. Besides, looks like fun! Good luck Piotr 17.04.2016 11:46 PM "Derek Bruening via llvm-dev" <llvm-dev at lists.llvm.org> napisał(a): TL;DR: We plan to build a suite of compiler-based dynamic instrumentation tools for analyzing targeted performance problems. These tools will all live under a new "EfficiencySanitizer" (or "esan") sanitizer umbr...

...n the compiler. Data working set size data is also not quite usable by the compiler. Esan's design tradeoffs are also not the same as PGO. The former allows more overhead and is less restricted -- it can go deeper. David > -- Sean Silva > > On Sun, Apr 17, 2016 at 2:46 PM, Derek Bruening via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> TL;DR: We plan to build a suite of compiler-based dynamic instrumentation >> tools for analyzing targeted performance problems. These tools will all >> live under a new "EfficiencySanitizer" (or "...

...s can prove that some >> accesses always read initialized memory), >> and a fast start-up. >> Our preliminary measurements show 3x-4x slowdown; compare it to >> Memchecks's 20x and DrMemory's 10x. >> (See >> http://groups.csail.mit.edu/commit/papers/2011/bruening-cgo11-drmemory.pdf for >> those numbers). >> But this brings the major issue as well: msan needs to see all program >> events, including system calls and reads/writes in system libraries, >> so we either need to compile *everything* with msan or use a binary >> transla...

On Tue, Apr 19, 2016 at 1:18 PM, Filipe Cabecinhas <filcab at gmail.com> wrote: > Thanks for proposing this. It seems like it might be an interesting > tool for us too. But this proposal seems a bit hand-wavy, and I think > it's missing some crucial info before we start heading this way. > > At least for the tools you are currently starting to implement, it > would be

...Renato Golin via llvm-dev wrote: > Hi Derek, > > I'm not an expert in any of these topics, but I'm excited that you > guys are doing it. It seems like a missing piece that needs to be > filled. > > Some comments inline... > > > On 17 April 2016 at 22:46, Derek Bruening via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> We would prefer to trade off accuracy and build a >> less-accurate tool below our overhead ceiling than to build a high-accuracy >> but slow tool. > > I agree with this strategy. > > As a first approach, ma...

Dear All, We have a new release of Clang with SAFECode technology for detecting memory safety errors. Memory safety checking (SAFECode for short) can be turned on with a single command line switch to clang/clang++. The SAFECode techniques do not change the behavior of the clang/clang++ compilers in any way when the switch is turned off, so this can be used as a drop-in replacement for