为什么英特尔线程构建模块 (TBB)parallel_for的开销如此之大？根据第 3.2.2 节Automatic ChunkingTutorial.pdf大约半毫秒。这是教程中的一个尝试：
注意：通常一个循环需要至少一百万个时钟周期才能使 parallel_for 提高其性能。例如，在 2 GHz 处理器上花费至少 500 微秒的循环可能会受益于 parallel_for。
从我目前所读到的内容来看，TBB 在内部使用线程池（工作线程池）模式，它通过最初只产生工作线程一次（花费数百微秒）来防止这种糟糕的开销。
那么什么是花时间呢？使用互斥锁的数据同步不是那么慢吗？此外，TBB 不使用无锁数据结构进行同步吗？
从我目前所读到的内容来看，TBB 在内部使用线程池（工作线程池）模式，它通过最初仅产生工作线程一次（花费数百微秒）来防止这种糟糕的开销。
是的，TBB 预先分配线程。它不会在看到 时物理地创建和加入工作线程parallel_for。OpenMP 和其他并行库都进行预分配。
但是，从池中唤醒线程并将逻辑任务分派给线程仍然存在开销。是的，TBB 利用无锁数据结构来最小化开销，但它仍然需要一些并行开销（即串行部分）。这就是为什么 TBB 手册建议避免非常短的循环。
通常，您必须有足够的工作才能获得并行加速。我认为即使是 1 毫秒（=1,000 微秒）也太小了。根据我的经验，为了看到有意义的加速，我需要将执行时间增加大约 100 毫秒。
如果您真的关心 TBB 的并行开销parallel_for，那么尝试简单的静态调度可能是值得的。我对 TBB 的静态调度实现不太了解。但是，您可以轻松尝试 OpenMP 的：omp parallel for schedule(static). 我相信这个开销将是并行的最小成本。但是，由于它使用的是静态调度，动态调度的好处（尤其是当工作负载不均匀时）将失去。