<div dir="ltr">You are right that regex has many ARC operations from libFoundation. Another outlier in terms of the number of ARC operations is binary-tree. In this case, ARC operations are from the user code, and the optimizer couldn't make much difference.<div><br></div><div>Other than these two, the optimizer seems working pretty well in removing ARC operations.<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 17, 2017 at 1:34 PM David P Grove <<a href="mailto:groved@us.ibm.com">groved@us.ibm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><p class="gmail_msg"><tt class="gmail_msg"><a href="mailto:swift-dev-bounces@swift.org" class="gmail_msg" target="_blank">swift-dev-bounces@swift.org</a> wrote on 02/16/2017 09:48:28 PM:</tt><br class="gmail_msg"><tt class="gmail_msg">> <br class="gmail_msg">> I was curious about the overhead of ARC and started profiling some <br class="gmail_msg">> benchmarks found in the Computer Language Benchmark Game (http://<br class="gmail_msg">> <a href="http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=swift" class="gmail_msg" target="_blank">benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=swift</a>). <br class="gmail_msg">> So far, it seems that ARC sequence optimization is surprisingly good<br class="gmail_msg">> and most benchmarks don't have to perform ARC operations as often as<br class="gmail_msg">> I expected. I have some questions regarding this finding.</tt><br class="gmail_msg"><tt class="gmail_msg">> <br class="gmail_msg">> I compiled all benchmarks with "-O -wmo" flags and counted the <br class="gmail_msg">> number of calls to ARC runtime (e.g., swift_rt_swift_retain) using Pin.</tt><br class="gmail_msg"><tt class="gmail_msg">> <br class="gmail_msg">> 1. Reference counting is considered to have high overhead due to <br class="gmail_msg">> frequent counting operations which also have to be atomic. At least<br class="gmail_msg">> for the benchmarks I tested, it is not the case and there is almost <br class="gmail_msg">> no overhead. Is it expected behavior? Or is it because the <br class="gmail_msg">> benchmarks are too simple (they are all single-file programs)? How <br class="gmail_msg">> do you estimate the overhead of ARC would be?</tt><br class="gmail_msg"><tt class="gmail_msg">> <br class="gmail_msg"></tt><br class="gmail_msg"></p></div><div class="gmail_msg"><p class="gmail_msg"><tt class="gmail_msg">hmm, I wonder if your method of profiling is really finding all the ARC operations. The Swift version of regex-dna is about 25x slower than the Java version (on Linux). I looked at some prof profiles about a month ago and at the time roughly 80% of all execution samples were attributed to swift_retain/swift_release operations coming from CoreFoundation's regex implementation. </tt><br class="gmail_msg"><br class="gmail_msg"><tt class="gmail_msg">--dave</tt><br class="gmail_msg"><br class="gmail_msg"><i class="gmail_msg">(See attached file: regex-dna.svg)</i><br class="gmail_msg">
</p></div>
</blockquote></div></div></div>