[swift-dev] Profiling ARC

[Michael Gottesman]

> On Feb 20, 2017, at 6:31 PM, Jiho Choi <jray319 at gmail.com> wrote:
> 
> 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.
> 
> 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.

Sure. I wasn't saying anything about the number of ARC operations in that benchmark. I just wanted to be clear which benchmark was being talked about that is all.

> 
> On Mon, Feb 20, 2017 at 5:20 PM Michael Gottesman <mgottesman at apple.com <mailto:mgottesman at apple.com>> wrote:
> Are you talking about this one (there are two)?
> 
> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=swift&id=1 <http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=swift&id=1>
> 
> Michael
>> On Feb 20, 2017, at 2:24 PM, Jiho Choi via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
> 
>> 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.
>> 
>> Other than these two, the optimizer seems working pretty well in removing ARC operations.
>> 
>> On Fri, Feb 17, 2017 at 1:34 PM David P Grove <groved at us.ibm.com <mailto:groved at us.ibm.com>> wrote:
>> swift-dev-bounces at swift.org <mailto:swift-dev-bounces at swift.org> wrote on 02/16/2017 09:48:28 PM:
>> > 
>> > I was curious about the overhead of ARC and started profiling some 
>> > benchmarks found in the Computer Language Benchmark Game (http://
>> > benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=swift <http://benchmarksgame.alioth.debian.org/u64q/measurements.php?lang=swift>). 
>> > So far, it seems that ARC sequence optimization is surprisingly good
>> > and most benchmarks don't have to perform ARC operations as often as
>> > I expected.  I have some questions regarding this finding.
>> > 
>> > I compiled all benchmarks with "-O -wmo" flags and counted the 
>> > number of calls to ARC runtime (e.g., swift_rt_swift_retain) using Pin.
>> > 
>> > 1. Reference counting is considered to have high overhead due to 
>> > frequent counting operations which also have to be atomic.  At least
>> > for the benchmarks I tested, it is not the case and there is almost 
>> > no overhead.  Is it expected behavior?  Or is it because the 
>> > benchmarks are too simple (they are all single-file programs)?  How 
>> > do you estimate the overhead of ARC would be?
>> > 
>> 
>> 
>> 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.  
>> 
>> --dave
>> 
>> (See attached file: regex-dna.svg)
> 
>> _______________________________________________
> 
>> 
>> swift-dev mailing list
>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170220/2ca6404b/attachment.html>