使用OpenMP并行化的峰值查找代码为何比串行代码更慢？

针对你64×5120灰度图像的场景，OpenMP并行版本反而更慢，主要有以下几个关键原因：

• 线程调度开销远超并行收益
  你的图像仅64行，按行分配并行任务时，最多需要64个线程，但线程的创建、销毁以及调度本身存在固定开销。而串行处理64行的总计算量极小（单遍历每行5120个元素的操作耗时微乎其微），并行引入的额外开销直接抵消甚至超过了并行带来的计算收益。

• 任务粒度太小
  每行最大值的计算属于轻量操作，单线程处理一行的时间极短。如果每个线程仅负责1-2行的计算，线程间的调度、同步开销占比会远高于实际计算时间，导致整体效率下降。

• 缓存伪共享问题
  存储每行最大值的结果数组通常是连续内存布局，多个线程同时写入数组中相邻的元素时，这些元素可能处于同一个CPU缓存行内。频繁的缓存行失效和一致性同步会带来额外开销，拖慢并行执行速度。

• 编译器优化差异
  串行代码往往能被编译器充分优化（比如自动向量化、循环展开、寄存器重排等），而并行代码因引入OpenMP指令，可能限制了编译器的部分优化策略，甚至并行区域内的单线程执行效率不如串行版本。

• OpenMP默认设置不合理
  如果没有手动指定线程数，系统可能创建远超CPU核心数的线程，导致频繁的上下文切换；或者使用了不适合的调度策略（比如默认调度在任务数远小于线程数时，会出现大量线程空转），进一步增加额外开销。

内容的提问来源于stack exchange，提问作者이재혁