使用OpenMP并行化for循环代码未提速反而变慢，求分析原因

问题根本不在if语句，而是rand()函数的线程安全性问题：
rand()内部维护了一个全局状态变量，多线程调用时会通过隐式互斥锁保护这个状态，导致所有线程都要排队等待调用rand()，完全失去并行意义，甚至因为线程调度和锁竞争的开销，比单线程慢很多。

修复方案 #

1. 使用线程安全的随机数生成函数

替换rand()为rand_r()（POSIX标准支持），每个线程维护独立的随机种子，避免锁竞争：

#include <omp.h>
#include <stdlib.h>
#include <time.h>

int main() {
    int N = 10000000; // 建议增大N，让并行收益覆盖开销
    int count = 0;
    int i;
    double x, y;

    // 可选：手动设置线程数，匹配CPU核心数
    omp_set_num_threads(4);

#pragma omp parallel for private(i, x, y) reduction(+:count)
    for (i = 0; i < N; i++) {
        // 每个线程使用独立的种子，避免重复随机序列
        unsigned int seed = omp_get_thread_num() + time(NULL) * 1000;
        x = rand_r(&seed) / ((double)RAND_MAX + 1);
        y = rand_r(&seed) / ((double)RAND_MAX + 1);

        if (x*x + y*y < 1) {
            ++count;
        }
    }

    double pi = 4.0 * count / N;
    return 0;
}

如果是C代码，更推荐使用C11引入的<random>库，比如std::mt19937，每个线程实例化一个独立的随机数生成器，安全性和随机性都更好。

2. 调整循环粒度与线程数

• 原代码中N=10000太小，线程创建、调度和reduction的开销会超过并行计算的收益，建议把N增大到1e6或1e7级别。
• 线程数不要超过CPU的物理核心数，否则会频繁触发上下文切换，增加额外开销。可以用omp_set_num_threads()手动设置，或者让OpenMP自动匹配核心数。

关于if语句的说明 #

这个if分支逻辑简单，分支预测的开销可以忽略，而且你已经用了reduction(+:count)来处理计数的并行累加，没有原子操作的额外开销，所以if语句不是导致代码变慢的原因。

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