[swift-dev] Profiling ARC

[Jiho Choi]

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.

On Mon, Feb 20, 2017 at 5:20 PM Michael Gottesman <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
>
> Michael
>
> On Feb 20, 2017, at 2:24 PM, Jiho Choi via swift-dev <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> wrote:
>
> 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).
> > 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
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170221/8e33d89b/attachment.html>