为何简单C++ OpenMP并行for循环反而更慢？

我有一个简单的for循环，尝试用OpenMP并行化，但并行版本反而比串行版本更慢。相关函数与循环代码如下：

template<typename T, class UnaryOperation>
void State::apply_diagmatrix(const std::vector<T>& matrix, const UnaryOperation& transformation)
{
#pragma omp parallel for
    for (uint64_t i=0; i<dim_; ++i) {
        state_[i] *= transformation(matrix[i]);
    }
}

其中state_是std::vector<std::complex<double>>类型的成员变量。调用该函数时，传入的UnaryOperation定义为：

auto exp_func = [dt](double matrix_term) {
    return std::complex<double>{std::cos(dt*matrix_term), -std::sin(dt*matrix_term)};
};

即使当dim_ > 4096时，并行版本仍比串行版本慢——原本预期4096次exp_func执行的并行收益会远大于线程开销。代码分析显示apply_diagmatrix函数占用了相当大的性能开销，理论上并行化应该能带来明显收益。但单独对该循环做基准测试时，只要dim_ > 512，并行版本就有明显优势。为什么集成到大型代码中就无法获得收益？可能的原因有哪些？

补充说明：目前缺少足够上下文，正在准备最小可复现示例。

可能的原因分析 #

• 缓存伪共享与竞争：大型程序中，state_或matrix数组可能与其他数据共享缓存行，多线程同时访问相邻元素时会频繁触发缓存行失效，导致缓存同步开销剧增，抵消并行计算的收益。单独测试时数据内存布局更规整，缓存命中率更高，不会出现这类问题。
• 线程池的创建/销毁开销：OpenMP的线程池在首次进入并行区域时会创建线程，若apply_diagmatrix的调用间隔中存在大量串行操作，线程可能被销毁或进入休眠状态，每次调用都需要重新初始化线程，开销被放大。单独测试时循环连续运行，线程池保持活跃，开销被平均摊薄。
• 系统资源抢占：大型程序中可能存在其他并行任务、IO操作或后台进程，抢占了CPU核心资源，导致apply_diagmatrix的并行线程无法充分利用计算资源。单独测试时程序独占CPU，并行效率能最大化发挥。
• 编译器优化差异：单独测试时，编译器可以针对孤立的循环做更激进的优化（比如并行+向量化的联合优化）；但集成到大型项目中，全局优化等级可能被降低，或者函数内联时机改变，导致并行版本的优化效果大打折扣。
• 内存带宽瓶颈：大型程序的其他部分可能正在大量读写内存，导致内存带宽饱和。apply_diagmatrix的并行执行会进一步加剧内存竞争，每个线程的内存访问延迟升高，反而不如串行单线程的连续内存访问效率高。
• OpenMP调度策略不匹配：默认的static调度在负载均匀的场景下高效，但如果大型程序中dim_的取值波动较大，或者线程数与CPU核心数不匹配，调度开销会显著增加。单独测试时dim_固定，调度策略的效率更高。

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