C++ OpenMP线程预分配自身使用内存的性能影响分析

void reserve1(vector<vector<int>>& vec, size_t siz) {
  for (auto& v : vec) {
    v.reserve(siz);
  }
}

void reserve2(vector<vector<int>>& vec, size_t siz) {
#pragma omp parallel default(shared) num_threads(vec.size())
  {
    vec[omp_get_thread_num()].reserve(vec);
  }
}

void doSomething(vector<int>& v) {
  // 对v做读写密集型操作
}

int main() {
  vector<vector<int>> data(omp_get_num_threads());
  size_t theSize =  1000000;
  reserve1(data, theSize); OR reserve2(data, theSize); <===================================

  // 此处执行非并行逻辑

#pragma omp parallel default(shared) num_threads(vec.size())
  {
    doSomething(data[omp_get_thread_num()]);
  }

  return 0;
}

注意：示例代码中reserve2存在明显笔误，vec[omp_get_thread_num()].reserve(vec);的参数应为siz，否则代码无法正常运行，以下分析均基于修正笔误后的逻辑展开。

你梳理的三点结论全部成立，具体说明如下：

• 并行分配提速的优势成立：当前主流内存分配器（tcmalloc、jemalloc、新版glibc的ptmalloc）都针对多线程场景做了优化，每个线程持有独立的分配缓存、内存arena，分配大内存时不会争抢全局锁，多核场景下并行分配速度明显高于主线程串行分配。
• 线程操作自身分配内存更快的优势成立：这不是经验玄学，有明确的硬件和运行时逻辑支撑。一是NUMA架构下的内存首触策略，操作系统会把物理内存页分配给第一个写入该页的线程所在CPU对应的NUMA节点，后续该线程访问本地NUMA节点的内存，延迟比跨节点访问低30%~120%不等*（该收益前提是线程不会被OS跨NUMA节点调度，若运行环境无绑核配置，收益会有波动）*；二是分配器操作内存元数据时，对应缓存行会留在当前核的L1/L2缓存中，刚分配完马上访问时缓存命中率更高。
• 并行区域固有开销的劣势成立：OpenMP开启并行区有固定的fork/join开销，通常在几微秒到几十微秒量级，如果分配操作本身耗时比这个开销还小，并行反而会拖慢速度。

额外优势 #

• 摊薄缺页中断开销：reserve仅预留虚拟地址空间，物理内存是第一次写入时触发缺页中断才实际分配的。并行分配时每个线程自行处理负责内存的缺页，不会把所有缺页压力堆在主线程上，大内存场景下能节省不少时间。
• 降低分配器后续操作开销：如果内存是主线程串行分配的，这些内存块会先进入主线程的线程本地缓存（tcache），后续工作线程对vector做扩容、释放操作时，需要跨线程转移内存块所有权，走更慢的公共分配路径；线程自己分配的内存本身就在自己的tcache里，后续push_back扩容、析构释放的路径更短，开销更小。
• 重复执行场景下开销可被摊薄：你提到main函数逻辑会重复执行数千次，OpenMP是用线程池复用工作线程的，不会每次开并行区都重新创建销毁线程，执行次数越多，并行区的固定开销占比越低。

额外劣势 #

• 代码鲁棒性更差：reserve2硬绑定了线程号和vector下标，一旦后续调整线程数、或者OpenMP运行时没有拉起等于vec.size()的线程，就会出现越界访问、部分vector未被reserve的问题；串行的reserve1没有这类隐式依赖，逻辑更稳妥。
• 老环境下可能反向变慢：如果运行环境用的是非常老旧的单锁malloc实现（比如早于2.17版本的glibc ptmalloc），并行分配时所有线程会争抢同一个全局分配锁，性能比串行还差。
• 存在额外线程唤醒开销：如果调用reserve2前工作线程都处于休眠状态，强制拉起等于vec.size()的线程会带来额外调度开销，小内存场景下这个开销占比很高。

• 线程数量的影响
  • 线程数<=4、且运行在单NUMA节点的普通消费级设备上时，并行分配收益极低，并行区开销占比高，reserve1通常更快。
  • 线程数等于物理核数、且设备是多NUMA节点的多路服务器（比如双路/四路CPU的服务器，核数在16以上）时，并行分配的NUMA亲和收益、并行提速收益会非常明显，reserve2性能可能比reserve1高1~3倍。
  • 线程数超过物理核数、用到超线程时，内存分配是带宽密集型操作，超线程对这类操作的加速效果极差，并行收益会快速下跌，甚至不如串行。
• 预分配大小theSize的影响
  • theSize很小（单vector预留空间小于几十KB）时，内存分配本身耗时极短，并行区的固定开销会盖过所有收益，reserve2更慢。
  • theSize较大（单vector预留空间在几MB以上，比如示例里1e6个int对应4MB空间）时，内存分配耗时、NUMA亲和的影响占绝对主导，reserve2的优势会非常明显。
  • 如果theSize设置得远大于实际需要的大小，并行分配会提前触发大量不必要的物理内存映射，还会浪费内存，反而拖慢整体速度。

如果线程i仅对专属的data[i]进行读写操作，data[i]由线程i自身分配、或是由其他线程（例如非并行区域中的主线程）分配，是否会对运行性能产生影响？

会产生影响，影响幅度取决于运行环境：

• 在多NUMA节点的服务器、大内存分配的场景下，影响非常明显，核心来源是NUMA跨节点访问的高延迟、分配器跨线程操作内存的额外开销，性能差距可达1倍以上。
• 在单NUMA节点的普通消费级设备、小内存分配的场景下，影响很小，通常只有几个百分点的差异，大部分场景下感知不到。

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