为啥 OpenMP 减少在共享内存结构上比 MPI 慢?

Posted

技术标签:

【中文标题】为啥 OpenMP 减少在共享内存结构上比 MPI 慢?【英文标题】:Why OpenMP reduction is slower than MPI on share memory structure?为什么 OpenMP 减少在共享内存结构上比 MPI 慢? 【发布时间】:2021-09-18 06:19:13 【问题描述】:

我尝试测试两个向量的内积的 OpenMP 和 MPI 并行实现(动态计算元素值)并发现 OpenMP 比 MPI 慢。 我使用的 MPI 代码如下,

#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <omp.h>
#include <mpi.h>


int main(int argc, char* argv[])

    double ttime = -omp_get_wtime();
    int np, my_rank;
    MPI_Init(&argc, &argv);
    MPI_Comm_size(MPI_COMM_WORLD, &np);
    MPI_Comm_rank(MPI_COMM_WORLD, &my_rank);

    int n = 10000;
    int repeat = 10000;

    int sublength = (int)(ceil((double)(n) / (double)(np)));
        int nstart = my_rank * sublength;
        int nend   = nstart + sublength;
    if (nend >n )
    
           nend = n;        
       sublength = nend - nstart;
       


        double dot = 0;
    double sum = 1;
    
    int j, k;
    double time = -omp_get_wtime();
    for (j = 0; j < repeat; j++)
    
                double loc_dot = 0;
            for (k = 0; k < sublength; k++)
            
            double temp = sin((sum+ nstart +k  +j)/(double)(n));
            loc_dot += (temp * temp);
           
        MPI_Allreduce(&loc_dot, &dot, 1, MPI_DOUBLE, MPI_SUM, MPI_COMM_WORLD);
            sum += (dot/(double)(n));
    
    time += omp_get_wtime();
    if (my_rank == 0)
    
            ttime += omp_get_wtime();
        printf("np = %d sum = %f, loop time = %f sec, total time = %f \n", np, sum, time, ttime);
    
        return 0;       

我尝试了几种不同的 OpenMP 实现。 这是不复杂且接近我能达到的最佳性能的版本。

#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <omp.h>


int main(int argc, char* argv[])


    int n = 10000;
    int repeat = 10000;


    int np = 1;
    if (argc > 1)
    
        np = atoi(argv[1]);
    
        omp_set_num_threads(np);
        
        int nstart =0;
        int sublength =n;

        double loc_dot = 0;
    double sum = 1;
     #pragma omp parallel
     
    int i, j, k;
        
    double time = -omp_get_wtime();

    for (j = 0; j < repeat; j++)
    
            #pragma omp for reduction(+: loc_dot)  
            for (k = 0; k < sublength; k++)
            
            double temp = sin((sum+ nstart +k  +j)/(double)(n));
            loc_dot += (temp * temp);
           
                #pragma omp single 
                
           sum += (loc_dot/(double)(n));
           loc_dot =0;
        
    
    time += omp_get_wtime();
        #pragma omp single nowait
        printf("sum = %f, time = %f sec, np = %d\n", sum, time, np);
     
   
   return 0;        

这是我的测试结果:

OMP
sum = 6992.953984, time = 0.409850 sec, np = 1
sum = 6992.953984, time = 0.270875 sec, np = 2
sum = 6992.953984, time = 0.186024 sec, np = 4
sum = 6992.953984, time = 0.144010 sec, np = 8
sum = 6992.953984, time = 0.115188 sec, np = 16
sum = 6992.953984, time = 0.195485 sec, np = 32

MPI
sum = 6992.953984, time = 0.381701 sec, np = 1
sum = 6992.953984, time = 0.243513 sec, np = 2
sum = 6992.953984, time = 0.158326 sec, np = 4
sum = 6992.953984, time = 0.102489 sec, np = 8
sum = 6992.953984, time = 0.063975 sec, np = 16
sum = 6992.953984, time = 0.044748 sec, np = 32

谁能告诉我我错过了什么? 谢谢!

更新: 我为 OMP 编写了一个可接受的 reduce 函数。现在的性能接近 MPI 减少功能。代码如下。

#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <omp.h>

double darr[2][64];
int    nreduce=0;
#pragma omp threadprivate(nreduce)


double OMP_Allreduce_dsum(double loc_dot,int tid,int np)

       darr[nreduce][tid]=loc_dot;
       #pragma omp barrier
       double dsum =0;
       int i;   
       for (i=0; i<np; i++)
       
           dsum += darr[nreduce][i];
       
       nreduce=1-nreduce;
       return dsum;


int main(int argc, char* argv[])



    int np = 1;
    if (argc > 1)
    
        np = atoi(argv[1]);
    
        omp_set_num_threads(np);
    double ttime = -omp_get_wtime();

    int n = 10000;
    int repeat = 10000;
        
     #pragma omp parallel
     
        int tid = omp_get_thread_num();
    int sublength = (int)(ceil((double)(n) / (double)(np)));
        int nstart = tid * sublength;
        int nend   = nstart + sublength;
    if (nend >n )
    
           nend = n;        
       sublength = nend - nstart;
       
        
    double sum = 1;
    double time = -omp_get_wtime();

    int j, k;
    for (j = 0; j < repeat; j++)
    
                double loc_dot = 0;
            for (k = 0; k < sublength; k++)
            
            double temp = sin((sum+ nstart +k  +j)/(double)(n));
            loc_dot += (temp * temp);
           
           double dot =OMP_Allreduce_dsum(loc_dot,tid,np);
           sum +=(dot/(double)(n));
    
    time += omp_get_wtime();
        #pragma omp master
         
       ttime += omp_get_wtime();
       printf("np = %d sum = %f, loop time = %f sec, total time = %f \n", np, sum, time, ttime);
    
     
   
   return 0;        

【问题讨论】:

如果你在单核上运行你的代码有多快? 机器?操作系统?用的编译器?使用编译器标志?使用 MPI 实现?如果没有这些信息,任何人都只是猜测。 机器:Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz。操作系统:Centos-7,编译器:Intel 18.0.1。编译器标志:-qopenmp。编译命令:mpiicc -qopenmp r_mpi.c -o r_mpi。 icc -qopenmp r_omp.c -o r_omp。运行命令:mpiexec -n 4 r_mpi, r_omp 4。我不确定 MPI 的实现。 请使用优化标志,如-O3(根据您的需要,可能还有-march=native-ffast-math)!默认情况下,ICC 不应像任何其他编译器一样优化代码。 我已经尝试过 -O3 -march=native -ffast-math 和 -lm。那些标志会加速一点,但不会改变趋势。 【参考方案1】:

首先,此代码同步开销(软件和硬件)非常敏感,这导致 OpenMP 运行时实现和低端代码本身出现明显的奇怪行为。级处理器操作(例如缓存/总线效果)。实际上,每 45 毫秒执行一次基于 j 的循环的每次迭代都需要完全同步。这意味着 4.5 我们/迭代。在这么短的时间内,需要减少和广播在 32 个核心中的部分和传播。如果每个核心在一个共享的原子位置累积自己的值,例如每个原子添加需要 60 ns(可扩展 Xeon 处理器上的原子的实际开销),则将需要 32 * 60 ns = 1.92 us,因为到目前为止此过程是在 x86 处理器上按顺序完成的。由于障碍,这个额外的小时间占总执行时间的 43%!由于对原子变量的争用,时间安排往往更糟。此外,屏障本身很昂贵(它们通常在 OpenMP 运行时中使用原子实现,但可以更好地扩展)。

第一个 OpenMP 实现速度很慢,因为隐式同步和复杂的硬件缓存影响。实际上,omp for reduction 指令在其区域的末尾和omp single 执行一个隐式屏障。减少本身可以通过多种方式实现。 ICC 的 OpenMP 运行时使用了一个聪明的 tree-based atomic implementation,它应该可以很好地扩展(但并不完美)。此外,omp single 部分会导致一些缓存行弹跳。实际上,结果loc_dot 可能会存储在最后一个更新它的内核的缓存中,而执行此部分的线程可能会安排在另一个内核上。在这种情况下,处理器必须将缓存线从一个 L2 缓存移动到另一个(或直接从 L3 缓存中加载有关硬件状态的值)。同样的事情也适用于sum(它倾向于在内核之间移动,因为执行该部分的线程可能不会总是被安排在同一个内核上)。最后,sum 变量必须在每个内核上广播,以便它们可以开始新的迭代。

最后一个 OpenMP 实现要好得多,因为每个线程都在自己的本地数据上工作,它只使用一个屏障(这种同步对于算法是强制性的)并且更好地使用缓存。累积部分可能并不理想,因为所有内核都可能会获取先前位于所有其他 L1/L2 缓存上的数据,从而导致 all-to-all 广播模式。这种硬件操作几乎不能扩展,但也应该是顺序的。

请注意,最后一个 OpenMP 实现存在错误共享。实际上,darr 的项目将连续存储在内存中并共享相同的缓存行。因此,当一个线程写入darr 时,关联的内核将请求缓存线并使位于其他内核上的那些无效。这会导致内核之间的高速缓存行弹跳。但是,在当前的 x86 处理器上,缓存行是 64 字节,double 变量占用 8 个字节,因此每个缓存行有 8 个项目。因此,它减轻了缓存线反弹的影响,通常是 8 个内核超过 32 个内核。话虽如此,项目打包有一些好处,因为每个核心只需要 4 个缓存线获取来执行全局累积。为了防止错误共享,可以分配一个(8 倍)更大的数组并在项目之间保留一些空间,以便每个缓存行存储 1 个项目。目标处理器上的最佳策略可能是使用 基于树的原子缩减,就像 ICC OpenMP 运行时使用的那样。理想情况下,sum 减少和屏障可以合并在一起以获得更好的性能。这就是 MPI 实现可以在内部执行的操作 (MPI_Allreduce)。

请注意,所有实现都受到非常高的线程同步的影响。这是一个问题,因为由于某些操作系统/硬件事件(网络、存储设备、用户、系统进程等),某些内核上会定期发生上下文切换。一个关键问题是任何现代 x86 处理器上的频率缩放:并非所有内核都将以相同的频率工作,并且它们的频率会随着时间而变化。由于障碍,最慢的线程将减慢所有其他线程。在最坏的情况下,某些线程可能会被动地等待使某些内核进入睡眠状态(C 状态),然后根据平台配置需要更多时间来唤醒其他内核。

要点是:代码的同步程度越高,其缩放比例就越低,优化难度也越大

【讨论】:

谢谢,在 darr 元素之间添加空格以避免错误共享的想法很有帮助。

以上是关于为啥 OpenMP 减少在共享内存结构上比 MPI 慢?的主要内容,如果未能解决你的问题,请参考以下文章

OpenMP的简单使用教程

openacc 与 openmp 和 mpi 的区别?

我可以将 MPI 与共享内存一起使用吗

OpenMp实现并行化

在 UMA 机器上使用 MPI 的优势

数组结构的 MPI-3 共享内存