Search code examples
iosswiftasync-awaitgrand-central-dispatchswift-concurrency

Maximum number of threads with async-await task groups

My intent is to understand the “cooperative thread pool” used by Swift 5.5’s async-await, and how task groups automatically constrain the degree of concurrency: Consider the following task group code, doing 32 calculations in parallel:

func launchTasks() async {
    await withTaskGroup(of: Void.self) { group in
        for i in 0 ..< 32 {
            group.addTask { [self] in
                let value = doSomething(with: i)
                // do something with `value`
            }
        }
    }
}

While I hoped it would constrain the degree of concurrency, as advertised, I'm only getting two (!) concurrent tasks at a time. That is far more constrained than I would have expected:

enter image description here

If I use the old GCD concurrentPerform ...

func launchTasks2() {
    DispatchQueue.global().async {
        DispatchQueue.concurrentPerform(iterations: 32) { [self] i in
            let value = doSomething(with: i)
            // do something with `value`
        }
    }
}

... I get twelve at a time, taking full advantage of the device (iOS 15 simulator on my 6-core i9 MacBook Pro) while avoiding thread-explosion:

enter image description here

(FWIW, both of these were profiled in Xcode 13.0 beta 1 (13A5154h) running on Big Sur. And please disregard the minor differences in the individual “jobs” in these two runs, as the function in question is just spinning for a random duration; the key observation is the degree of concurrency is what we would have expected.)

It is excellent that this new async-await (and task groups) automatically limits the degree of parallelism, but the cooperative thread pool of async-await is far more constrained than I would have expected. And I see of no way to adjust these parameters of that pool. How can we better take advantage of our hardware while still avoiding thread explosion (without resorting to old techniques like non-zero semaphores or operation queues)?

Solution

  • This limitation on the cooperative thread pool on the simulator has been removed in Xcode 14.3 (without any mention to this change in the release notes).

    It looks like this curious behavior is a limitation of the simulator in Xcode 14.2 and earlier. If I run it on my physical iPhone 12 Pro Max, the async-await task group approach results in 6 concurrent tasks ...

    enter image description here

    ... which is essentially the same as the concurrentPerform behavior:

    enter image description here

    The behavior, including the degree of concurrency, is essentially the same on the physical device.

    One is left to infer that the simulator appears to be configured to constrain async-await more than what is achievable with direct GCD calls. But on actual physical devices, the async-await task group behavior is as one would expect.

    For what it is worth, the above was produced by Xcode 13 on MacBook Pro. I have repeated this two different Macs in Xcode 14.2 and got different results. Specifically, on my Intel 2018 MacBook Pro, the cooperative thread pool for my simulator had two threads. On my 2022 Mac Studio’s simulator, though, it was constrained to 3 threads:

    enter image description here

    It would appear that the size of the simulator’s cooperative thread pool is affected by the Mac hardware you use. But the point remains, that the cooperative thread pool is artificially constrained on the simulator.

    For comparison, here is a comparable “Points of Interest” run on a physical iPhone 12 Pro Max in Xcode 14.2:

    enter image description here