使用execution::par_unseq未并行化且无需链接TBB的技术问询

1. 注释TBB链接仍可编译运行的原因 #

G++的并行STL（<execution>）自带两种执行后端：

• 链接TBB时，使用TBB作为多线程并行执行后端；
• 未链接TBB时，编译器会自动启用串行模拟后端——它完全遵循并行接口的语义执行，但实际是单线程串行运行，因此代码能正常编译链接，只是没有并行效果。

2. par_unseq无性能提升的可能原因 #

(1) 未实际启用TBB并行后端 #

即使CMake配置了TBB依赖，但注释掉target_link_libraries(holes5 PUBLIC TBB::tbb)后，程序实际使用的是串行模拟后端，自然不会有并行加速。可以通过以下方式验证：

• Linux下用ldd holes5查看是否链接了libtbb.so；
• 编译时添加-DTBB_DEBUG或运行时设置TBB_VERBOSE=1环境变量，检查TBB是否初始化成功。

(2) 迭代器类型限制了并行效率 #

你使用views::filter过滤元素后，得到的是前向迭代器，而execution::par_unseq对前向迭代器的并行支持非常有限：

• G++的并行STL无法快速拆分前向迭代器的任务到多个线程，通常只能采用粗粒度并行甚至直接退化为串行；
• 若要高效并行，建议先将过滤后的元素收集到vector这类支持随机访问迭代器的容器中，再对容器使用par_unseq执行for_each。

(3) Lambda的副作用不满足线程安全要求 #

execution::par_unseq要求传入的函数对象必须是线程安全的：

• 如果你的Lambdacdtt中的副作用（比如修改共享变量、调用非线程安全函数）没有做同步处理（如互斥锁、原子操作），编译器或TBB会自动禁用并行，避免数据竞争；
• 即使强行并行，线程竞争带来的开销也会抵消并行收益，甚至导致结果错误（你结果正常，大概率是编译器退化成了串行执行）。

(4) 任务粒度太小 #

如果每个元素的计算量极小，并行执行的线程调度、上下文切换开销会远大于并行带来的收益，最终表现为和串行性能无差异。可以尝试增大单个任务的计算量，或者合并小任务，观察性能变化。

内容的提问来源于stack exchange，提问作者Ludovic Aubert