<div dir="ltr">I used the older versions (binary-trees #6 & binary-trees #7) which I downloaded a couple of weeks ago. It seems like they updated binary-trees benchmarks since then.<div><br></div><div>I just profiled the one you linked and got a similar result. The optimizer removed about 30% of ARC operations, which is better than almost none in the older versions. However, compared to other benchmarks, where most of ARC operations in the user code are removed, it is still pretty low.</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 20, 2017 at 5:20 PM Michael Gottesman <<a href="mailto:mgottesman@apple.com">mgottesman@apple.com</a>> wrote:<br></div><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="gmail_msg">Are you talking about this one (there are two)?<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><a href="http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=swift&id=1" class="gmail_msg" target="_blank">http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=swift&id=1</a></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Michael</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 20, 2017, at 2:24 PM, Jiho Choi via swift-dev <<a href="mailto:swift-dev@swift.org" class="gmail_msg" target="_blank">swift-dev@swift.org</a>> wrote:</div><br class="m_6741773049348946667Apple-interchange-newline gmail_msg"></blockquote></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Other than these two, the optimizer seems working pretty well in removing ARC operations.<br class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Fri, Feb 17, 2017 at 1:34 PM David P Grove <<a href="mailto:groved@us.ibm.com" class="gmail_msg" target="_blank">groved@us.ibm.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" 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></div></blockquote></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">
_______________________________________________</div></blockquote></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">swift-dev mailing list<br class="gmail_msg"><a href="mailto:swift-dev@swift.org" class="gmail_msg" target="_blank">swift-dev@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-dev" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-dev</a><br class="gmail_msg"></div></blockquote></div></div></div></blockquote></div>