Parallel processing OpenMP开销和linux内核版本

我使用了一个小测试程序来测试OpenMP并行化的效率 使用mpfr/gmp库的任意精度的递归计算。 正如预期的那样，OpenMP开销使并行版本起初速度变慢，但是 使用足够的位使并行版本变得更快

顺序循环如下所示：

....
for ( i = 0; i < 1000; i++ ) {
    mpfr_set_d ( z1, 0.0, MPFR_RNDN );
    mpfr_set_d ( z2, 0.0, MPFR_RNDN );
    ...
    iter = 0;
    while ( iter < 10000 ) {
         mpfr_sqr ( tmp1, z1, MPFR_RNDN );
         mpfr_sqr ( tmp2, z2, MPFR_RNDN );
         mpfr_sub ( tr, tmp1, tmp2, MPFR_RNDN );
         mpfr_add ( tr, tr, cr, MPFR_RNDN );
         mpfr_mul_2si ( tmp3, z1, 1, MPFR_RNDN );
         ...
         iter++;
    }
}

并行版本：

....
omp_set_dynamic(0);
for ( i = 0; i < 10; i++ ) {
    mpfr_set_d ( z2, 0.0, MPFR_RNDN );
    mpfr_set_d ( z1, 0.0, MPFR_RNDN );
    ...
    iter = 0;
    while ( iter < 10000 ) {
#pragma omp parallel num_threads(4)
    {
        switch ( omp_get_thread_num() ) {
        case 0:
        mpfr_sqr ( tmp1, z1, MPFR_RNDN );
        mpfr_sqr ( tmp2, z2, MPFR_RNDN );
        mpfr_sub ( tr, tmp1, tmp2, MPFR_RNDN );
        mpfr_add ( tr, tr, cr, MPFR_RNDN ); break;
        case 1:
        mpfr_mul_2si ( tmp3, z1, 1, MPFR_RNDN );
        mpfr_mul ( ti, tmp3, z2, MPFR_RNDN );
        mpfr_add ( ti, ti, ci, MPFR_RNDN ); break;
        ...
        mpfr_mul_2si ( tti, tti, 1, MPFR_RNDN ); break;
        }
    }
        mpfr_set ( z1, tr, MPFR_RNDN );
        mpfr_set ( z2, ti, MPFR_RNDN );
        mpfr_set ( d1, ttr, MPFR_RNDN );
        mpfr_set ( d2, tti, MPFR_RNDN );
        iter++;
    }
}

以秒为单位的运行时间系统A：顺序

320位：11 640位：16 960位：21 2560位：60 5000位：152 以秒为单位的运行时间系统A：并行

320位：15 640位：16 960位：18 2560位：32 5000位：65 以秒为单位的运行时间系统B：顺序

320位：13 640位：18 960位：27 2560位：80 5000位：202 以秒为单位的运行时间系统B：并行

320位：51 640位：54 960位：56 2560位：76 5000位：128 系统A是 软呢帽19 内核3.11.10-200.fc19.x86_64

IntelR CoreTM i7-4770 CPU@3.40GHz

系统B是 Linux Centos 6.5 内核2.6.32-431.1.2.0.1.el6.x86_64

IntelR XeonR CPU E5-2697 v2@2.70GHz

ltrace显示的被调用函数/系统调用的百分比大致相同。 这两个系统都使用最新的gmp、mpfr和gcc版本。 为什么系统B如此糟糕，例如OpenMP开销高出许多倍 而不是系统A？Linux内核在这方面做得更好了吗？ 有没有内核参数等，我应该看看？CPU硬件差异/限制？还有其他解释吗？ 我必须在B上安装Fedora 19才能修复此问题吗

更新：谢谢你的提示。它确实改变了系统B的结果

以秒为单位的运行时间系统B：并行

320位：51->23 640位：54->26 960位：56->29 2560位：76->47 5000位：128->99

---

B仍然落后于A，但差距已经小得多。

将OMP\u PROC\u BIND环境变量设置为TRUE，然后再次运行测试。对于串行版本，请使用taskset将程序固定到单个CPU内核。建议：您的系统a有一个新的Haswell处理器，带有TSX，因此可以使用硬件锁省略。如果您使用任何垂直部分或可比较部分，这可能会弥补一点差距。