ios - 具有异步等待任务组的最大线程数

Question

我的目的是了解 Swift 5.5 的 async-await 使用的“协作线程池”，以及任务组如何自动约束并发程度：考虑以下任务组代码，并行进行 32 次计算：

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

虽然我希望它会限制并发程度，但正如宣传的那样，我一次只能获得两个（！）并发任务。这比我预期的要受限制得多：

如果我使用旧的 GCD concurrentPerform...

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

...我一次得到 12 个，充分利用设备（我的 6 核 i9 MacBook Pro 上的 iOS 15 模拟器），同时避免线程爆炸：

（FWIW，这两个都在 Big Sur 上运行的 Xcode 13.0 beta 1 (13A5154h) 中进行了分析。请忽略这两个运行中各个“工作”的细微差异，因为所讨论的功能只是随机旋转; 关键观察是并发程度是我们所期望的。）

这个新的 async-await（和任务组）自动限制并行度非常好，但是 async-await 的协作线程池比我预期的要受限制得多。而且我认为无法调整该池的这些参数。我们如何才能更好地利用我们的硬件，同时仍然避免线程爆炸（不求助于非零信号量或操作队列等旧技术）？

Answer 1

看起来这种奇怪的行为是模拟器的限制。如果我在我的物理 iPhone 12 Pro Max 上运行它，异步等待任务组方法会导致 6 个并发任务......

concurrentPerform...这与行为基本相同：

包括并发程度在内的行为在物理设备上基本相同。

可以推断，模拟器似乎被配置为对 async-await 的约束比直接 GCD 调用所能实现的更多。但是在实际的物理设备上，异步等待任务组的行为正如人们所期望的那样。