<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 Jan 31, 2017, at 12:07 AM, Mikio Takeuchi <<a href="mailto:mikio.takeuchi@gmail.com" class="">mikio.takeuchi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hi Michael,<br class=""><br class="">> If you are interested in the perf difference with ARC atomics, Roman recently added a mode to the compiler called -assume-single-threaded that uses non-atomic reference counts anywhere.<br class=""><br class="">I think that is not exactly true. As of now, -assume-single-threaded option can eliminate atomic reference counts only for reference types. <br class=""><br class="">I tried -assume-single-threaded for compiling applications as well as swift runtime, and found that atomic reference counts were still used for value types and improvements were limited because of them.<br class=""><br class="">SIL Instructions on value types (such as CopyValue) are not subtype of RefCountingInst, therefore they don't have a mechanism to represent atomicity. </div></div></div></blockquote><div><br class=""></div><div>This is not an issue since currently copy value is lowered right after SILGen to instructions that /do/ have atomicity. My understanding is that the assume single threaded option runs a pass late to set these all to non-atomic.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> COW requires reference counts and, because of the lack of information, atomic reference counts are assumed at many places in their codegen and runtime.<br class=""></div></div></div></blockquote><div><br class=""></div><div>IMO again, this is not an issue due to the late pass.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class="">I made a prototype which returns the right atomicity based on the compiler option in order to eliminate atomic reference counts from generated code. I also modified value witness functions to eliminate atomic reference counts from them. With these changes, atomic reference counts almost disappeared. <br class=""></div></div></div></blockquote><div><br class=""></div><div>The value witness functions I think are the larger potential issue.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class="">If it makes sense, I am happy to contribute my changes to the community. <br class=""><br class="">I understand there are two problems with my prototype. <br class="">1) We may need to introduce a mechanism to represent atomicity for value types as well. It will open an opportunity for compiler to use non-atomic reference counts for thread-local values. <br class=""></div></div></div></blockquote><div><br class=""></div><div>Again, I do not think that is an issue since we lower these away today. This may require changes at a later time though once these value operations go further back into the compiler.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">2) We need to either extend value witness table to add non-atomic version of functions, or pass atomicity information to the functions as an extra parameter.<br class=""></div></div></div></blockquote><div><br class=""></div><div>Since your option makes an assumption that the whole program is single threaded, why couldn't we just emit the value witness functions such that they use non-atomic reference counts?</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class="">Since they are not trivial changes, I would like your endorsement before starting serious work.<br class=""></div></div></div></blockquote><div><br class=""></div><div>Send a PR and lets talk about it. [i.e. what Roman said ; )]</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div>-- Mikio<br class=""><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">2016-12-18 5:49 GMT+09:00 Michael Gottesman via swift-dev <span dir="ltr" class=""><<a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@swift.org</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><span class=""><div class="">On Dec 17, 2016, at 11:13 AM, Brian Gesiak via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@swift.org</a>> wrote:</div><br class="m_-1088950599532420518Apple-interchange-newline"></span><span class=""><div class=""><div dir="ltr" class="">Hello all!<div class=""><br class=""></div><div class="">I really enjoyed Chris Lattner's slides from his talk at IBM <<a href="http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf" target="_blank" class="">http://researcher.watson.ibm.<wbr class="">com/researcher/files/us-<wbr class="">lmandel/lattner.pdf</a>>. </div><div class=""><br class=""></div><div class="">The speaker notes mention ARC:</div><div class=""><br class=""></div><div class="">"There are two principle downsides to ARC that people cite: one is the need for atomic increment/decrements, which can be slow." [...] "The performance problems it can cause are real in some important cases"</div><div class=""><br class=""></div><div class="">Can someone point me to a good resource that explains these problems? I guess atomic reference count changes create overhead in multithreaded applications? Are there more detailed explorations into this topic?</div></div></div></span></blockquote><div class=""><br class=""></div><div class="">With a proper concurrency model, I believe you can make most reference counting operations local (my opinion). I have done some explorations in this area in the past using what I call thread local vs global reference counts and using marked concurrency boundaries to mediate transitions in between them (moving from thread local -> atomic of course if one escapes in an undefined way).</div><div class=""><br class=""></div><div class="">If you are interested in the perf difference with ARC atomics, Roman recently added a mode to the compiler called -assume-single-threaded that uses non-atomic reference counts anywhere.</div><div class=""><br class=""></div><div class="">There are some interesting optimizations in this area as well, specifically even today, COW gives a nice guarantee of thread localness allowing you to eliminate atomic reference counts once you have a uniqued cow data structure.</div><div class=""><br class=""></div><div class="">Michael</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Thanks!</div><div class=""><br class=""></div><div class="">- Brian Gesiak</div><div class=""><br class=""></div></div>
______________________________<wbr class="">_________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-dev" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-dev</a><br class=""></div></blockquote></div><br class=""></div><br class="">______________________________<wbr class="">_________________<br class="">
swift-dev mailing list<br class="">
<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-dev</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>