mingw32-pthreads-w32在Windows下是否正常？OpenMP并行性能不及串行疑问

首先可以排除是mingw32-pthreads-w32库工作异常的可能，该场景下并行性能低于串行是OpenMP入门非常常见的问题，主要原因如下：

• 计算规模太小：当前测试用的num_steps仅为100万，这个量级下单线程执行本身耗时极短，多线程创建、调度、同步的额外开销已经完全覆盖了并行计算带来的收益。可以尝试将num_steps调整到1亿及以上量级，再重新对比二者的性能差异。
• 未开启编译器优化：性能测试场景必须开启编译器优化参数，GCC下可添加-O2参数。很多初学者编译OpenMP程序时仅添加-fopenmp参数不开启优化，此时未优化的并行代码性能远低于开了优化的串行代码属于正常现象。正确的编译指令参考：gcc -fopenmp -O2 源码文件名.c
• 并行实现存在冗余开销：你当前的实现用critical临界区完成结果同步，虽然此处单次写入的开销极低，但完全可以用OpenMP原生的reduction规约子句替代，既简化代码逻辑，也能进一步降低同步开销。简化的并行实现参考：

void parallel(unsigned int num_steps){
    double step = 1.0/(double)(num_steps);
    double sum = 0.0;
    double start=omp_get_wtime();
    #pragma omp parallel for reduction(+:sum)
    for (long i = 0; i < num_steps;i++){
        double x = i * step;
        sum += (4.0 / (1.0 + x * x));
    }
    double pi = step * sum;
    double end=omp_get_wtime();
    printf("Time taken : %0.9lf\n",end-start);
    printf("The value of pi is : %0.9lf\n",pi);
}

• CPU睿频调度影响：你使用的i5-8265U处理器单线程睿频最高可达3.9GHz，而多线程满载时的稳定睿频通常仅为3GHz左右，单线程运行时的更高运行频率也会进一步压缩并行程序的性能优势。
• 32位程序性能限制：你使用的是32位的mingw32工具链，32位程序的浮点运算性能本身弱于64位程序，建议换用64位的mingw-w64工具链测试，性能表现会更符合预期。

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