Hi Guilherme, Instrumenting all memory accesses is only one cause of slowdown. Another equally important cause is poisoning the heap memory on malloc/free and poisoning the stack memory on function entry/exit. Yet another one, is the growth of total memory usage due to redzones and quarantine (extra RAM usage typically costs extra CPU cycles) If you don't look at these factors you are unlikely to get a good model.
--kcc On Mon, Sep 3, 2018 at 12:28 PM Guilherme <[email protected]> wrote: > Hi all, > > We are running a few experiments to try to predict the performance slowdown > of Address Sanitizer. Our hypothesis is that an executable with more memory > accesses would take longer than one with fewer. We tried to correlate > the number of loads/stores in the LLVM IR with the slowdown introduced by > ASAN but the correlation we've found is too weak to support our hypothesis. > > I am attaching a chart showing the correlation we've computed. We've used > the following notation: > > time_ratio = (time without asan) / (time with asan) > stores_visible = stores_instructions_IR / stores_total > loads_visible = loads_instructions_IR / loads_total > > However, the hypothesis still makes sense for us. Therefore, we think we > might be missing a few factors. So, if we would like to predict the ASAN > performance overhead on a program, which instructions, other than > loads/stores, are more likely to cause Address Sanitizer to slowdown the > program? > > Regards, > > Guilherme > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
