使用OpenMP测试多核心加速未观测到线性加速比的技术求助

先把你的测试代码和环境信息整理清楚：

测试代码 #

int main() { 
    using u64_t = unsigned long long; 
    u64_t n = 1e9; 
    u64_t* a = new u64_t[n]; 
    #pragma omp parallel for 
    for (u64_t i=0; i<n; ++i) { 
        a[i] = i; 
    } 
}

编译与测试 #

• 编译命令：g++ -fopenmp -O3 test.cpp
• 耗时测试：
  • export OMP_NUM_THREADS=1：4.485s
  • export OMP_NUM_THREADS=2：2.916s（加速比~1.54）
  • export OMP_NUM_THREADS=3：2.571s（加速比~1.74）

核心原因：内存带宽瓶颈 #

说白了，你的代码是纯内存密集型任务，而非计算密集型——整个循环里几乎没有任何计算逻辑，只是把数值i写入数组a的对应位置。这时候性能的瓶颈根本不在CPU的计算能力，而是在内存的读写速度上：

• 单线程时，CPU已经在全力利用内存带宽了；当你增加线程，多个线程会同时争抢有限的内存带宽资源，此时再增加线程，整体的写入速度不会线性增长，因为内存带宽已经接近饱和。
• 从你的测试数据也能看出来：1→2线程时还有明显提升，但2→3线程的提升幅度已经很小，继续加到4线程的话，耗时大概率只会再降一点点，甚至几乎不变。

其他次要影响因素 #

除了内存瓶颈，还有几个小因素也会拉低加速比：

• 线程调度开销：虽然OpenMP的线程池机制已经把开销降到很低，但创建/调度线程本身还是有一点点成本。对于这种几乎没计算的任务，这点开销的占比会被放大，拖慢整体加速比。
• 缓存竞争：单线程时，CPU缓存可以充分利用数组的空间局部性；多线程时，每个线程负责的数组段会占用各自的缓存空间，当缓存不够大时，会出现缓存命中率下降的情况，进一步影响性能。
• 负载均衡（影响极小）：虽然parallel for默认会均匀拆分任务，但如果数组大小不是线程数的整数倍，个别线程会多处理几个元素。不过你这里n=1e9是个很大的数，这个影响几乎可以忽略。

验证线性加速比的建议 #

如果想看到接近线性的加速比，可以把代码改成计算密集型任务，比如给每个元素加一些复杂计算：

#pragma omp parallel for 
for (u64_t i=0; i<n; ++i) { 
    a[i] = i * i + (i % 1000) * sqrt(i); // 增加计算量，让CPU成为瓶颈
}

这时候CPU的计算能力会成为性能瓶颈，多线程的加速比会更接近线性。另外，你也可以试试把n改小到能完全放进CPU的L3缓存里（比如n=1e6），此时内存瓶颈消失，多线程也能带来更明显的加速。

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