<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 Feb 17, 2017, at 11:30 AM, David P Grove via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><p class=""><tt class=""><a href="mailto:swift-dev-bounces@swift.org" class="">swift-dev-bounces@swift.org</a> wrote on 02/16/2017 09:48:28 PM:</tt><br class=""><tt class="">> <br class="">> I was curious about the overhead of ARC and started profiling some <br class="">> benchmarks found in the Computer Language Benchmark Game (http://<br class="">> <a href="http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=swift" class="">benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=swift</a>). <br class="">> So far, it seems that ARC sequence optimization is surprisingly good<br class="">> and most benchmarks don't have to perform ARC operations as often as<br class="">> I expected. I have some questions regarding this finding.</tt><br class=""><tt class="">> <br class="">> I compiled all benchmarks with "-O -wmo" flags and counted the <br class="">> number of calls to ARC runtime (e.g., swift_rt_swift_retain) using Pin.</tt><br class=""><tt class="">> <br class="">> 1. Reference counting is considered to have high overhead due to <br class="">> frequent counting operations which also have to be atomic. At least<br class="">> for the benchmarks I tested, it is not the case and there is almost <br class="">> no overhead. Is it expected behavior? Or is it because the <br class="">> benchmarks are too simple (they are all single-file programs)? How <br class="">> do you estimate the overhead of ARC would be?</tt><br class=""><tt class="">> <br class=""></tt><br class=""><tt class="">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=""></p></div></div></blockquote><div>Question. Where is this regex-dna benchmark, is it in the swift benchmark suite?</div><blockquote type="cite" class=""><div class=""><div class=""><p class=""><br class=""><tt class="">--dave</tt><br class=""><br class=""><i class="">(See attached file: regex-dna.svg)</i><br class="">
</p></div>
<span id="cid:1__=0ABB0A59DFF9EF118f9e8a93df938690918c0AB@"><regex-dna.svg></span>_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></blockquote></div><br class=""></body></html>