> On Feb 20, 2017, at 6:31 PM, Jiho Choi <jray...@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 <mgottes...@apple.com > <mailto:mgottes...@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@swift.org >> <mailto:swift-dev@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 <gro...@us.ibm.com >> <mailto:gro...@us.ibm.com>> wrote: >> swift-dev-boun...@swift.org <mailto:swift-dev-boun...@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@swift.org <mailto:swift-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-dev >> <https://lists.swift.org/mailman/listinfo/swift-dev>
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
