<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 30, 2015, at 10:15 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" class="">chisophugis@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Thu, Jul 30, 2015 at 8:10 PM, Jake VanAdrighem<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:jvanadrighem@gmail.com" target="_blank" class="">jvanadrighem@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><span class="">On Wed, Jul 29, 2015 at 7:27 PM, Sean Silva<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:chisophugis@gmail.com" target="_blank" class="">chisophugis@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><span class="">On Wed, Jul 29, 2015 at 6:55 PM, Bob Wilson<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:bob.wilson@apple.com" target="_blank" class="">bob.wilson@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jul 29, 2015, at 4:56 PM, Alexey Samsonov <<a href="mailto:vonosmas@gmail.com" target="_blank" class="">vonosmas@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class="">Do relaxed atomics actually introduce that much of slowdown?</div></div></blockquote><div class=""><br class=""></div></span>I would definitely want to see some data showing that they do not slow things down before we decide to do this unconditionally. We’ve discussed this issue several times in the past. My recollection is those discussions ended with an acknowledgement there is a tradeoff between speed and accuracy and that we don’t all agree on where we want to be on that spectrum. Adding options to let people choose would be one solution. Good data, on a variety of platforms, showing that it doesn’t make much difference would be another way to resolve it.</div></div></blockquote><div class=""><br class=""></div></span><div class="">+1</div><div class=""><br class=""></div><div class="">In my testing, the overhead of the existing instrumentation is about a 2x slowdown, which is starting to get close to the range it would be very difficult to play an instrumented game. I wouldn't want to make this much slower. I'm glad to test this for you; I'll try to get around to this this week.</div><div class=""><br class=""></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Sean and I tested Alexey's patch on one of our large titles and got somewhere in the area of 2.5 to 3x worse performance than without AtomicRMW. For the game we tested, it was basically unplayable.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">We also noticed that the top 100 functions (out of 10's of thousands; i.e. <1%) accounted for over 97% of the total counts (and just the top 10 cover more than 50% IIRC). The few we manually looked into seemed like they would be trivially inlined anyway and/or their high count otherwise doesn't seem to really contribute much useful information to the optimizer since we should already be "getting those right" (stuff like simple constructors, getters, or vector operators).</div><div class=""><br class=""></div><div class="">Obviously this is a discussion for another thread, but there seems to be enormous scope for reduction in our profiling overhead for those interested in doing that; even just a simple file of 100 functions passed to the compiler instructing those functions to not be instrumented would decrease the profiling overhead by over 2 orders of magnitude for this title, based on the above data.</div><div class=""><br class=""></div><div class="">-- Sean Silva</div></div></div></blockquote><div><br class=""></div>We had some users request the same thing for the purpose of code coverage testing. If you already know that some code is heavily exercised, there’s no need to instrument it to check for coverage. No one has gotten around to implementing that yet, but it sounds like something that would be useful.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Jake Van Adrighem</div><div class=""><div class="h5"><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""></div><div class="">Also, in the past David Li suggested that his findings were that not using atomic operations "<span style="font-size: 13px;" class="">only contribute</span></div><div class=""><span style="font-size: 13px;" class="">to very small count variations" </span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msg_llvm-2Ddev_ScLa2xIdo9s_Ow1FPDVVRIoJ&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=SLAHuMS097rE0HJBsM_g5H8e-AltKY6DSKt4fmyXXdg&s=j6dXaeF32Dce88n0W1vgcjiII4AQnur8LuEPiKzgwCc&e=" target="_blank" class="">https://groups.google.com/d/msg/llvm-dev/ScLa2xIdo9s/Ow1FPDVVRIoJ</a></div><div class="">CC'ing David in case he has more input to the discussion.</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">-- Sean Silva</div></font></span><div class=""><div class=""><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class=""><br class=""></div><div class="">You're intentionally introducing a data race, this doesn't look good to me at all. However, I'm not confident about</div><div class="">what's allowed in LLVM IR - it's not C++ where any source-level data race is UB, but not an x86 assembly either.</div></div><div class="gmail_extra" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><br class=""><div class="gmail_quote">On Wed, Jul 29, 2015 at 4:43 PM, Justin Bogner<span class=""> </span><span dir="ltr" class=""><<a href="mailto:mail@justinbogner.com" target="_blank" class="">mail@justinbogner.com</a>></span><span class=""> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><span class="">Alexey Samsonov <<a href="mailto:vonosmas@gmail.com" target="_blank" class="">vonosmas@gmail.com</a>> writes:<br class="">> samsonov created this revision.<br class="">> samsonov added reviewers: dnovillo, bogner.<br class="">> samsonov added a subscriber: llvm-commits.<br class="">><br class="">> Since we introduced counters for functions in COMDAT sections (e.g.<br class="">> inline functions from STL headers), these headers can easily be<br class="">> incremented concurrently by multiple threads. Replace load-add-store<br class="">> with a single "atomicrmw add" with monotonic memory ordering.<br class=""><br class=""></span>This significantly changes the performance characteristics of this code,<br class="">pessimizing single-threaded users and potentially making the<br class="">multithreaded performance issues even worse.<br class=""><br class="">It's fine to add an option to lower these to atomics, since this does<br class="">guarantee accuracy, but I think we need a switch to choose which kind of<br class="">lowering we're interested in in that case.<br class=""><div class=""><div class=""><br class="">><span class=""> </span><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11579&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=lDx1rX-3B32oZTA_vCe21kRN0Y14ujW2ePnnU3JiUX4&s=tiiUXsu0al8aXyrPKSc28tcPx4YG5wxgSglC63-ASTQ&e=" rel="noreferrer" target="_blank" class="">http://reviews.llvm.org/D11579</a><br class="">><br class="">> Files:<br class="">>   lib/Transforms/Instrumentation/InstrProfiling.cpp<br class="">><br class="">> Index: lib/Transforms/Instrumentation/InstrProfiling.cpp<br class="">> ===================================================================<br class="">> --- lib/Transforms/Instrumentation/InstrProfiling.cpp<br class="">> +++ lib/Transforms/Instrumentation/InstrProfiling.cpp<br class="">> @@ -147,9 +147,9 @@<br class="">>    IRBuilder<> Builder(Inc->getParent(), *Inc);<br class="">>    uint64_t Index = Inc->getIndex()->getZExtValue();<br class="">>    Value *Addr = Builder.CreateConstInBoundsGEP2_64(Counters, 0, Index);<br class="">> -  Value *Count = Builder.CreateLoad(Addr, "pgocount");<br class="">> -  Count = Builder.CreateAdd(Count, Builder.getInt64(1));<br class="">> -  Inc->replaceAllUsesWith(Builder.CreateStore(Count, Addr));<br class="">> +  Builder.CreateAtomicRMW(AtomicRMWInst::Add, Addr, Builder.getInt64(1),<br class="">> +                          llvm::Monotonic);<br class="">> +  assert(Inc->use_empty() && "InstrProfIncrementInst has uses!");<br class="">>    Inc->eraseFromParent();<br class="">>  }<br class=""><br class=""></div></div></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>--<span class=""> </span><br class=""><div class=""><div dir="ltr" class="">Alexey Samsonov<br class=""><a href="mailto:vonosmas@gmail.com" target="_blank" class="">vonosmas@gmail.com</a></div></div></div></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline !important;" class="">llvm-commits mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class="">llvm-commits@cs.uiuc.edu</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a></div></blockquote></div><br class=""></div><br class="">_______________________________________________<br class="">llvm-commits mailing list<br class=""><a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank" class="">llvm-commits@cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br class=""><br class=""></blockquote></div></div></div><br class=""></div></div><br class="">_______________________________________________<br class="">llvm-commits mailing list<br class=""><a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank" class="">llvm-commits@cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a></blockquote></div></div></div></div></div></blockquote></div></div></blockquote></div><br class=""></body></html>