如何优化OpenMP并行内存写入的加速比？

问题背景 #

你尝试用OpenMP并行化一个对零散分布对象的double字段赋值的循环，目标是通过多核分摊内存写入开销，但在M1 Mac上测试百万级数据时，加速比仅1.1x-1.2x，2核后再增加线程无收益。原始代码及优化尝试如下：

原始代码 #

bool Individual::_SetFitnessScaling_1(double source_value, EidosObject **p_values, size_t p_values_size)
{
    if ((source_value < 0.0) || (std::isnan(source_value)))
        return true;
    
#pragma omp parallel for schedule(static) default(none) shared(p_values_size) firstprivate(p_values, source_value) if(p_values_size >= EIDOS_OMPMIN_SET_FITNESS_S1)
    for (size_t value_index = 0; value_index < p_values_size; ++value_index)
        ((Individual *)(p_values[value_index]))->fitness_scaling_ = source_value;
    
    return false;
}

带__restrict的优化尝试 #

bool Individual::_SetFitnessScaling_1(double source_value, EidosObject **p_values, size_t p_values_size)
{
    if ((source_value < 0.0) || (std::isnan(source_value)))
        return true;
    
#pragma omp parallel default(none) shared(p_values_size) firstprivate(p_values, source_value) if(p_values_size >= EIDOS_OMPMIN_SET_FITNESS_S1)
    {
        EidosObject * const * __restrict local_values = p_values;
        
#pragma omp for schedule(static)
        for (size_t value_index = 0; value_index < p_values_size; ++value_index)
            ((Individual *)(local_values[value_index]))->fitness_scaling_ = source_value;
    }
    
    return false;
}

核心瓶颈分析 #

你的场景本质是随机内存写入的共享带宽瓶颈+缓存一致性开销，这是硬件层面的限制，而非编译器或OpenMP调度的问题：

• 每个fitness_scaling_分布在不同缓存行，线程写入时需要先执行RFO（Read For Ownership）操作获取缓存行独占权，该操作会占用内存总线带宽。
• M1采用统一内存架构（UMA），所有核心共享内存总线，当2个线程已经占满写入带宽后，新增线程只会增加总线竞争，无法提升吞吐量。
• __restrict无法解决该问题，它仅用于消除编译器的别名顾虑，而你的瓶颈在硬件内存子系统，而非编译优化。

优化建议 #

1. 调整OpenMP变量共享策略 #

• 将p_values设为shared而非firstprivate：p_values是只读的指针数组，多线程读取无竞争，firstprivate会给每个线程复制指针，完全没必要，反而增加线程初始化开销。
• source_value可设为shared：它是只读的double值，多线程读取不会有竞争，避免firstprivate的复制开销。
  调整后的并行指令：

#pragma omp parallel for schedule(static) default(none) shared(p_values_size, p_values, source_value) if(p_values_size >= EIDOS_OMPMIN_SET_FITNESS_S1)

2. 优化并行阈值 #

当前EIDOS_OMPMIN_SET_FITNESS_S1=900过低，M1的线程启动开销会抵消小数据量的并行收益。建议将阈值提高到5000-10000，确保仅当数据量足够大时才启用并行。

3. 尝试内存预取 #

在循环中预取下一个要写入的地址，让内存子系统提前准备缓存行，减少等待时间：

for (size_t value_index = 0; value_index < p_values_size; ++value_index)
{
    // 预取下一个元素的fitness_scaling_地址，1表示写入操作，3表示中等优先级
    if (value_index + 1 < p_values_size)
        __builtin_prefetch(&((Individual *)(p_values[value_index+1]))->fitness_scaling_, 1, 3);
    ((Individual *)(p_values[value_index]))->fitness_scaling_ = source_value;
}

4. 绑定线程到大核 #

M1包含4个性能核（大核）和4个能效核（小核），小核的内存带宽更低。通过环境变量绑定线程到大核，避免混合调度影响性能：

export OMP_PROC_BIND=true
export OMP_PLACES=cores

5. 尝试调整调度策略 #

默认static调度是平均分配循环迭代，尝试dynamic调度并设置合理的chunk size，让线程负载更均衡（效果可能有限，但可测试）：

#pragma omp parallel for schedule(dynamic, 1000) default(none) shared(p_values_size, p_values, source_value) if(p_values_size >= EIDOS_OMPMIN_SET_FITNESS_S1)

总结 #

随机内存写入的场景天生难以获得线性加速比，因为内存总线是共享瓶颈。上述优化能尽量减少并行的额外开销，缓解硬件瓶颈，但加速比可能仍无法接近核数。如果业务场景允许，可考虑批量处理对象或调整内存布局，但根据你的补充说明，这些方案不可行，因此上述调整是当前最优的尝试方向。

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