如何解决为什么 OpenMP 减少在共享内存结构上比 MPI 慢?
我尝试测试 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",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,time = 0.243513 sec,time = 0.158326 sec,time = 0.102489 sec,time = 0.063975 sec,time = 0.044748 sec,np = 32
谁能告诉我我错过了什么? 谢谢!
更新: 我已经为 OMP 编写了一个可接受的 reduce 函数。现在性能已经接近MPI的reduce功能了。代码如下。
#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,ttime);
}
}
return 0;
}
解决方法
首先,此代码对同步开销(软件和硬件)非常敏感,导致 OpenMP 运行时实现和低级处理器操作(例如缓存/总线效果)。实际上,每 45 毫秒执行一次的基于 j
的循环的每次迭代都需要完全同步。这意味着 4.5 us/迭代。在这么短的时间内,需要减少和广播在 32 个内核中传播的部分和。如果每个内核在共享原子位置累积自己的值,例如每个原子添加 60 ns(可扩展至强处理器上原子的实际开销),则需要 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 缓存中的数据,从而导致全对全广播模式。这种硬件操作几乎不能扩展,但也应该是顺序的。
请注意,最后一个 OpenMP 实现存在错误共享。实际上,darr
的项将连续存储在内存中并共享相同的缓存行。因此,当一个线程写入 darr
时,关联的内核将请求缓存行并使位于其他内核上的缓存行无效。这会导致内核之间的缓存线反弹。但是,在当前的 x86 处理器上,缓存行是 64 字节,double
变量占用 8 字节,导致每个缓存行有 8 个项目。因此,它减轻了缓存线弹跳的影响,通常为 8 个内核而不是 32 个内核。话虽如此,项目打包有一些好处,因为每个内核只需要 4 个缓存行获取来执行全局累积。为了防止错误共享,可以分配一个(8 倍)更大的数组并在项目之间保留一些空间,以便每个缓存行存储 1 个项目。目标处理器上的最佳策略可能是使用基于树的原子归约,就像 ICC OpenMP 运行时使用的那样。理想情况下,sum
减少和屏障可以合并在一起以获得更好的性能。这是 MPI 实现可以在内部执行的操作 (MPI_Allreduce
)。
请注意,所有实现都受到非常高的线程同步的影响。这是一个问题,因为由于某些操作系统/硬件事件(网络、存储设备、用户、系统进程等),某些核心上会定期发生某些上下文切换。一个关键问题是任何现代 x86 处理器上的频率缩放:并非所有内核都以相同的频率工作,而且它们的频率会随着时间而变化。由于障碍,最慢的线程会减慢所有其他线程的速度。在最坏的情况下,某些线程可能会被动等待,使某些内核进入休眠状态(C 状态),然后根据平台配置花费更多时间唤醒其他内核,从而进一步减慢其他线程的速度。
要点是:
代码越同步,其扩展性越低,优化难度也越大。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。