Merge pull request swiftlang#12074 from atrick/benchinfo

Author: swift-ci

benchmark/single-source/AnyHashableWithAClass.swift

@@ -14,6 +14,20 @@
 // upcast the instance to the type that introduces the Hashable
 // conformance.
 
+import TestsUtils
+
+// 23% _swift_dynamicCast
+// 23% _swift_release_
+// 18% _swift_stdlib_makeAnyHashableUsingDefaultRepresentation
+// 11% _swift_stdlib_makeAnyHashableUpcastingToHashableBaseType
+// 16% _swift_retain_[n]
+//  5% swift_conformsToProtocol
+public var AnyHashableWithAClass = BenchmarkInfo(
+  name: "AnyHashableWithAClass",
+  runFunction: run_AnyHashableWithAClass,
+  tags: [.abstraction, .runtime, .cpubench]
+)
+
 class TestHashableBase : Hashable {
   var value: Int
   init(_ value: Int) {

benchmark/single-source/Exclusivity.swift

@@ -17,6 +17,36 @@
 
 import TestsUtils
 
+// At -Onone
+// 25% swift_beginAccess
+// 15% tlv_get_addr
+// 15% swift_endAccess
+public var ExclusivityGlobal = BenchmarkInfo(
+  name: "ExclusivityGlobal",
+  runFunction: run_accessGlobal,
+  tags: [.runtime, .cpubench]
+)
+// At -Onone
+// 23% swift_retain
+// 22% swift_release
+//  9% swift_beginAccess
+//  3% swift_endAccess
+public var ExclusivityInMatSet = BenchmarkInfo(
+  name: "ExclusivityInMatSet",
+  runFunction: run_accessInMatSet,
+  tags: [.runtime, .cpubench]
+)
+// At -Onone
+// 25% swift_release
+// 23% swift_retain
+// 16% swift_beginAccess
+//  8% swift_endAccess
+public var ExclusivityIndependent = BenchmarkInfo(
+  name: "ExclusivityIndependent",
+  runFunction: run_accessIndependent,
+  tags: [.runtime, .cpubench]
+)
+
 // Initially these benchmarks only measure access checks at -Onone. In
 // the future, access checks will also be emitted at -O.
 

benchmark/single-source/LinkedList.swift

@@ -14,6 +14,14 @@
 // utils/benchmark, with modifications for performance measuring.
 import TestsUtils
 
+// 47% _swift_retain
+// 43% _swift_release
+public var LinkedList = BenchmarkInfo(
+  name: "LinkedList",
+  runFunction: run_LinkedList,
+  tags: [.runtime, .cpubench, .refcount]
+)
+
 final class Node {
   var next: Node?
   var data: Int

benchmark/single-source/PolymorphicCalls.swift

@@ -22,6 +22,12 @@ applying a jump-threading in combination with the speculative devirtualization.
 
 import TestsUtils
 
+public var PolymorphicCalls = BenchmarkInfo(
+  name: "PolymorphicCalls",
+  runFunction: run_PolymorphicCalls,
+  tags: [.abstraction, .cpubench]
+)
+
 public class A {
     let b: B
     init(b:B) {

benchmark/single-source/SevenBoom.swift

@@ -13,6 +13,21 @@
 import TestsUtils
 import Foundation
 
+// 15% _swift_allocObject (String.bridgeToObjectiveC)
+// 14% [NSError dealloc]
+// 14% objc_allocWithZone
+// 10% _swift_allocObject
+// 11% _swift_release_dealloc
+//  8% objc_release
+//  7% objc_msgSend
+//  5% _swift_release_
+//  2% _swift_retain_
+public var SevenBoom = BenchmarkInfo(
+  name: "SevenBoom",
+  runFunction: run_SevenBoom,
+  tags: [.runtime, .exceptions, .bridging, .cpubench]
+)
+
 @inline(never)
 func filter_seven(_ input : Int) throws {
   guard case 7 = input else {

benchmark/utils/TestsUtils.swift

@@ -17,54 +17,54 @@ import Darwin
 #endif
 
 public enum BenchmarkCategories : CustomStringConvertible {
-// Validation "micro" benchmarks test a specific operation or critical path that
-// we know is important to measure.
-case validation
-// subsystems to validate and their subcategories.
-case api, Array, String, Dictionary, Codable, Set
-case sdk
-case runtime, refcount, metadata
-// Other general areas of compiled code validation.
-case abstraction, safetychecks, exceptions, bridging, concurrency
-
-// Algorithms are "micro" that test some well-known algorithm in isolation:
-// sorting, searching, hashing, fibonaci, crypto, etc.
-case algorithm
-
-// Miniapplications are contrived to mimic some subset of application behavior
-// in a way that can be easily measured. They are larger than micro-benchmarks,
-// combining multiple APIs, data structures, or algorithms. This includes small
-// standardized benchmarks, pieces of real applications that have been extracted
-// into a benchmark, important functionality like JSON parsing, etc.
-case miniapplication
-
-// Regression benchmarks is a catch-all for less important "micro"
-// benchmarks. This could be a random piece of code that was attached to a bug
-// report. We want to make sure the optimizer as a whole continues to handle
-// this case, but don't know how applicable it is to general Swift performance
-// relative to the other micro-benchmarks. In particular, these aren't weighted
-// as highly as "validation" benchmarks and likely won't be the subject of
-// future investigation unless they significantly regress.
-case regression
-
-// Most benchmarks are assumed to be "stable" and will be regularly tracked at
-// each commit. A handful may be marked unstable if continually tracking them is
-// counterproductive.
-case unstable
-
-// CPU benchmarks represent instrinsic Swift performance. They are useful for
-// measuring a fully baked Swift implementation across different platforms and
-// hardware. The benchmark should also be reasonably applicable to real Swift
-// code--it should exercise a known performance critical area. Typically these
-// will be drawn from the validation benchmarks once the language and standard
-// library implementation of the benchmark meets a reasonable efficiency
-// baseline. A benchmark should only be tagged "cpubench" after a full
-// performance investigation of the benchmark has been completed to determine
-// that it is a good representation of future Swift performance. Benchmarks
-// should not be tagged if they make use of an API that we plan on
-// reimplementing or call into code paths that have known opportunities for
-// significant optimization.
-case cpubench
+  // Validation "micro" benchmarks test a specific operation or critical path that
+  // we know is important to measure.
+  case validation
+  // subsystems to validate and their subcategories.
+  case api, Array, String, Dictionary, Codable, Set
+  case sdk
+  case runtime, refcount, metadata
+  // Other general areas of compiled code validation.
+  case abstraction, safetychecks, exceptions, bridging, concurrency
+   
+  // Algorithms are "micro" that test some well-known algorithm in isolation:
+  // sorting, searching, hashing, fibonaci, crypto, etc.
+  case algorithm
+   
+  // Miniapplications are contrived to mimic some subset of application behavior
+  // in a way that can be easily measured. They are larger than micro-benchmarks,
+  // combining multiple APIs, data structures, or algorithms. This includes small
+  // standardized benchmarks, pieces of real applications that have been extracted
+  // into a benchmark, important functionality like JSON parsing, etc.
+  case miniapplication
+   
+  // Regression benchmarks is a catch-all for less important "micro"
+  // benchmarks. This could be a random piece of code that was attached to a bug
+  // report. We want to make sure the optimizer as a whole continues to handle
+  // this case, but don't know how applicable it is to general Swift performance
+  // relative to the other micro-benchmarks. In particular, these aren't weighted
+  // as highly as "validation" benchmarks and likely won't be the subject of
+  // future investigation unless they significantly regress.
+  case regression
+   
+  // Most benchmarks are assumed to be "stable" and will be regularly tracked at
+  // each commit. A handful may be marked unstable if continually tracking them is
+  // counterproductive.
+  case unstable
+   
+  // CPU benchmarks represent instrinsic Swift performance. They are useful for
+  // measuring a fully baked Swift implementation across different platforms and
+  // hardware. The benchmark should also be reasonably applicable to real Swift
+  // code--it should exercise a known performance critical area. Typically these
+  // will be drawn from the validation benchmarks once the language and standard
+  // library implementation of the benchmark meets a reasonable efficiency
+  // baseline. A benchmark should only be tagged "cpubench" after a full
+  // performance investigation of the benchmark has been completed to determine
+  // that it is a good representation of future Swift performance. Benchmarks
+  // should not be tagged if they make use of an API that we plan on
+  // reimplementing or call into code paths that have known opportunities for
+  // significant optimization.
+  case cpubench
 
   public var description : String {
     switch self {

benchmark/utils/main.swift

@@ -124,6 +124,21 @@ import UTF8Decode
 import Walsh
 import XorLoop
 
+@inline(__always)
+private func registerBenchmark(_ bench: BenchmarkInfo) {
+  registeredBenchmarks.append(bench)
+}
+
+registerBenchmark(AnyHashableWithAClass)
+registerBenchmark(ArraySetElement)
+registerBenchmark(ExclusivityGlobal)
+registerBenchmark(ExclusivityInMatSet)
+registerBenchmark(ExclusivityIndependent)
+registerBenchmark(LinkedList)
+registerBenchmark(ObjectAllocation)
+registerBenchmark(PolymorphicCalls)
+registerBenchmark(SevenBoom)
+
 @inline(__always)
 private func addTo(
   _ testSuite: inout [String : ((Int) -> (), [BenchmarkCategories])],
@@ -134,14 +149,6 @@ private func addTo(
   testSuite[name] = (function, tags)
 }
 
-@inline(__always)
-private func registerBenchmark(_ bench: BenchmarkInfo) {
-  registeredBenchmarks.append(bench)
-}
-
-registerBenchmark(ArraySetElement)
-registerBenchmark(ObjectAllocation)
-
 // The main test suite: precommit tests
 addTo(&precommitTests, "AngryPhonebook", run_AngryPhonebook, [.validation, .api, .String])
 addTo(&precommitTests, "AnyHashableWithAClass", run_AnyHashableWithAClass, [.validation, .abstraction, .runtime])