为什么我的OpenMP程序运行时间不随线程数增加线性缩放？

• 计算规模过小，并行开销占比过高
  100万int元素的数组总大小仅4MB，完全可以装进CPU的L3缓存，单线程跑完两个循环仅需3.6ms，此时OpenMP的线程创建、屏障同步、任务调度的开销占总运行时间的比例非常高，线程数增加带来的计算收益很容易被并行开销抵消，无法实现线性缩放。
• 任务为内存密集型，遭遇带宽瓶颈
  你的代码包含数组初始化（写内存）和数组求和（读内存）两个操作，都是典型的内存密集型任务，核心计算逻辑没有运算量，性能上限受内存带宽限制。当线程数增加到内存带宽被打满后，继续加线程不会提升性能，反而会因为多线程争抢缓存、内存控制器调度开销增加导致性能下降。
• 线程调度与CPU调频的影响
  单线程运行时CPU通常会睿频到更高的单核频率，多线程运行时全核睿频频率会明显低于单核睿频，会抵消多线程的部分收益。同时如果你的CPU启用了超线程，或者系统存在NUMA架构，线程被调度到不同NUMA节点、或者超线程逻辑核心上运行时，内存访问延迟会升高，也会导致性能异常。你测试结果中3、4线程性能下降、5线程性能又反弹的情况，也和短时间运行下的线程调度波动直接相关。
• 调度参数设置不合理
  你设置schedule(static,16)将任务拆分为极小的块，1e6次迭代会产生62500个任务块，反而大幅提升了任务调度的开销。对于这种连续无依赖的大循环，直接使用默认的schedule(static)按线程数分大块即可，调度开销远低于小块拆分。
• 测量误差干扰
  单次毫秒级的运行时间测量误差极大，系统后台进程、IO操作的干扰都会直接影响测试结果。建议将整个计算逻辑重复运行数百上千次，取平均耗时排除偶然波动。

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