|
| 1 | +# coz-swift |
| 2 | + |
| 3 | +Swift support for the [`coz` causal profiler](https://github.com/plasma-umass/coz). |
| 4 | + |
| 5 | +A traditional profiler tells you *where* your program spends time. Coz tells you |
| 6 | +whether optimizing a line would actually make the program faster — which, in |
| 7 | +concurrent code, is a different question. |
| 8 | + |
| 9 | +Works on **Linux** and **macOS**. |
| 10 | + |
| 11 | +## Usage |
| 12 | + |
| 13 | +First [install `coz`](https://github.com/plasma-umass/coz#installation), then add |
| 14 | +the package: |
| 15 | + |
| 16 | +```swift |
| 17 | +.package(url: "https://github.com/plasma-umass/coz.git", from: "0.3.0") |
| 18 | +``` |
| 19 | + |
| 20 | +and depend on the `Coz` product: |
| 21 | + |
| 22 | +```swift |
| 23 | +.target(name: "MyApp", dependencies: [.product(name: "Coz", package: "coz")]) |
| 24 | +``` |
| 25 | + |
| 26 | +Mark the points where your program makes progress. For throughput — "I wish this |
| 27 | +happened more often": |
| 28 | + |
| 29 | +```swift |
| 30 | +import Coz |
| 31 | + |
| 32 | +for request in requests { |
| 33 | + handle(request) |
| 34 | + Coz.progress() // equivalent of COZ_PROGRESS |
| 35 | +} |
| 36 | +``` |
| 37 | + |
| 38 | +`Coz.progress("requests")` is the equivalent of `COZ_PROGRESS_NAMED`. |
| 39 | + |
| 40 | +For latency — "I wish this finished sooner" — bracket the operation: |
| 41 | + |
| 42 | +```swift |
| 43 | +try Coz.scope("request") { |
| 44 | + try handle(request) |
| 45 | +} |
| 46 | +``` |
| 47 | + |
| 48 | +`scope` fires its end counter even if the body throws. If you need the halves |
| 49 | +apart, `Coz.begin("request")` and `Coz.end("request")` are available. |
| 50 | + |
| 51 | +On a hot path, hold a counter instead of looking it up by name each time: |
| 52 | + |
| 53 | +```swift |
| 54 | +let requests = Coz.Counter(throughput: "requests") |
| 55 | +for request in batch { |
| 56 | + handle(request) |
| 57 | + requests.increment() |
| 58 | +} |
| 59 | +``` |
| 60 | + |
| 61 | +`Coz.isAvailable` reports whether the program is running under `coz run`. |
| 62 | + |
| 63 | +## Building and running |
| 64 | + |
| 65 | +Coz needs DWARF line tables, so build with debug information: |
| 66 | + |
| 67 | +``` |
| 68 | +swift build -c release -Xswiftc -g |
| 69 | +coz run --- .build/release/MyApp |
| 70 | +coz plot --text |
| 71 | +``` |
| 72 | + |
| 73 | +A plain `swift build` (debug) also works and carries debug info by default. |
| 74 | + |
| 75 | +## Example |
| 76 | + |
| 77 | +`Sources/CozToy` runs two threads per round; one does twice the work of the |
| 78 | +other, so it sits on the critical path. |
| 79 | + |
| 80 | +``` |
| 81 | +swift build -c release -Xswiftc -g |
| 82 | +coz run --- .build/release/CozToy |
| 83 | +coz plot --text |
| 84 | +``` |
| 85 | + |
| 86 | +``` |
| 87 | +Source Line | Slope | R² | Max Speedup | Points |
| 88 | +-----------------------------------------+---------+-------+-------------+------- |
| 89 | +swift/Sources/CozToy/main.swift:44 | 0.616 | 0.90 | + 46.9% | 9 |
| 90 | +swift/Sources/CozToy/main.swift:55 | 0.052 | 1.00 | + 4.7% | 2 |
| 91 | +``` |
| 92 | + |
| 93 | +Line 44 is inside `slowWork`'s loop and line 55 inside `fastWork`'s. Coz predicts |
| 94 | +that speeding up `slowWork` speeds up the program roughly proportionally, and |
| 95 | +finds `fastWork` nearly irrelevant. |
| 96 | + |
| 97 | +## Caveats |
| 98 | + |
| 99 | +Both of these come down to the same thing: **coz only understands threads and |
| 100 | +blocking primitives that it interposes.** It interposes `pthread_create`, |
| 101 | +`pthread_join`, pthread mutexes and condition variables. Everything below follows |
| 102 | +from that. |
| 103 | + |
| 104 | +**On macOS, coz cannot delay libdispatch's global queues.** Coz applies a virtual |
| 105 | +speedup by *delaying every other thread*, and it can only delay threads it knows |
| 106 | +about. On Darwin the global `DispatchQueue` workers are kernel-created |
| 107 | +pthread-workqueue threads that never call `pthread_create`. Coz will still |
| 108 | +*sample* them, so their lines appear in the profile, but the virtual speedup has |
| 109 | +nothing to slow down and every line comes out with a slope near zero. |
| 110 | + |
| 111 | +If your hot work runs on `DispatchQueue.global()` and every line reads as flat, |
| 112 | +that is why. Run the code you want to profile on a `Thread` or a plain `pthread`, |
| 113 | +as `Sources/CozToy` does. This does not affect Linux, where |
| 114 | +swift-corelibs-libdispatch creates its workers with `pthread_create`. |
| 115 | + |
| 116 | +**Blocking on a primitive coz cannot see will skew your results.** A thread |
| 117 | +blocked on a raw futex, a Mach semaphore, or a `DispatchSemaphore` still gets |
| 118 | +charged for the virtual delays it "should" have paid while it was asleep. If the |
| 119 | +thread that hits your progress point is the one doing the waiting, every line |
| 120 | +comes out with a *negative* slope. (This is not hypothetical — this example |
| 121 | +originally joined its threads with a `DispatchSemaphore` and reported exactly |
| 122 | +that.) |
| 123 | + |
| 124 | +Either block on something coz interposes — `pthread_join`, a pthread mutex or |
| 125 | +condvar — or tell coz about the primitive yourself: |
| 126 | + |
| 127 | +```swift |
| 128 | +Coz.preBlock() |
| 129 | +semaphore.wait() |
| 130 | +Coz.postBlock(skipDelays: true) // true: another thread woke us |
| 131 | + |
| 132 | +Coz.catchUp() // pay delays before we may wake someone |
| 133 | +semaphore.signal() |
| 134 | +``` |
| 135 | + |
| 136 | +These map to `COZ_PRE_BLOCK`, `COZ_POST_BLOCK` and `COZ_CATCH_UP` in `coz.h`. |
| 137 | + |
| 138 | +**Don't use a SIGPROF-based profiler at the same time.** Coz samples with |
| 139 | +`SIGPROF` and will fight anything else that wants it. |
| 140 | + |
| 141 | +**Progress points must be reached often enough.** Coz needs roughly five |
| 142 | +progress-point visits per experiment, and each experiment runs for about half a |
| 143 | +second. A program that reaches its progress point a dozen times in total will |
| 144 | +produce very few data points. |
| 145 | + |
| 146 | +**Swift optimizes counted loops aggressively.** A microbenchmark like |
| 147 | +`for i in 0..<n { acc &+= i }` gets folded to a closed form and deleted, leaving |
| 148 | +coz nothing to sample. This bites synthetic examples, not real programs. |
| 149 | + |
| 150 | +## How it works |
| 151 | + |
| 152 | +`Sources/CCoz/coz_shim.c` resolves `_coz_get_counter` and `_coz_add_delays` out |
| 153 | +of the injected `libcoz` with `dlsym(RTLD_DEFAULT, ...)`. That means the package |
| 154 | +needs neither `coz.h` at build time nor a system `coz-profiler` package, and a |
| 155 | +binary built against it runs normally when `libcoz` is absent — every entry point |
| 156 | +degrades to a no-op. |
| 157 | + |
| 158 | +Counter lookups are memoized in C, so a hot progress point does not pay for |
| 159 | +libcoz's lock and name table on every hit, and the Swift side holds no global |
| 160 | +mutable state (the package builds clean under Swift 6 strict concurrency). |
| 161 | + |
| 162 | +Incrementing is a relaxed atomic add. On macOS each progress point additionally |
| 163 | +calls `_coz_add_delays()`, because macOS has no per-thread sampling timer and a |
| 164 | +worker thread only discovers the virtual delay it owes when it reaches a progress |
| 165 | +point. This mirrors `_COZ_CHECK_DELAYS` in `include/coz.h`. |
0 commit comments