OpenMP阵列性能较差

OpenMP poor performance with arrays

本文关键字:性能 阵列 OpenMP      更新时间:2023-10-16

我有以下问题:我试图用openMP在c++中并行化一个非常简单的PDE求解器,但如果我增加线程数量,性能不会提高。该方程是一个简单的一维对流热方程。由于我在每个时间步长都需要解决方案,我决定使用2D阵列

double solution[iterationsTime][numPoints];

其中每一行包含特定时间步长的离散函数。更新通过for loop 完成

#pragma omp parallel default(shared) private(t, i, iBefore, iAfter)
{
for(t=0; t<iterationsTime; t++)
#pragma omp for schedule(auto) 
for(i=0; i<numPoints; i++) {
iBefore = (i==0)?numPoints-2:i-1;
iAfter = (i==numPoints-1)?1:i;
solution[t+1][i] = solution[t][iAfter] - solution[t][iBefore];
}

使用值iBefore和iAfter是因为我基本上将数组视为环形缓冲区,因此PDE具有周期性边界条件,并且域被视为环形。无论如何,对解决方案[t+1]的每次更新都需要对解决方案[t]进行一些计算,就像上面代码中显示的那样。我知道可伸缩性差的原因很可能是错误共享,所以我将2D矩阵转换为3D矩阵

double solution[iterationsTime][numPoints][PAD];

这使我能够确保在共享缓存线上不执行写操作,因为我可以改变PAD的大小。代码有点变化,因为现在每个值都将存储在中

solution[t][i][0];

中的以下一个

solution[t][i+1][0];

请注意,所需的内存是使用并行区域外的新运算符在堆上分配的。该代码运行良好,但不可扩展。我尝试过不同的时间表,如静态、动态、自动。。。我用编译它

g++ code.cpp -fopenmp -march=native -O3 -o out

我曾尝试删除或添加-march和-O3旗帜,但我看不到任何改进。我尝试过不同大小的PAD和环境变量,如OMP_PROC_BIND,但没有改进。在这一点上,我不知道是什么导致了表现的下降。这是代码

const int NX = 500; //DOMAIN DISCRETIZATION
const int PAD = 8; //PADDING TO AVOID FALSE SHARING
const double DX = 1.0/(NX-1.0); //STEP IN SPACE
const double DT = 0.01*DX; //STEP IN TIME
const int NT = 1000; //MAX TIME ITERATIONS
const double C = 10.0; //CONVECTION VELOCITY
const double K = 0.01; //DIFFUSION COEFFICIENT
int main(int argc, char **argv) {
omp_set_num_threads(std::atoi(argv[1]));  //SET THE REQUIRED NUMBER OF THREADS
//INTIALING MEMORY --> USING STD::VECTOR INSTEAD OF DOUBLE***
std::vector<std::vector<std::vector<double>>> solution(NT, std::vector<std::vector<double>>(NX, std::vector<double>(PAD,0)));
for (int i=0; i<NX; i++){
solution[0][i][0] = std::sin(i*DX*2*M_PI); //INITIAL CONDITION
}
int numThreads, i, t, iBefore, iAfter;
double energy[NT]{0.0}; //ENERGY of the solution --> e(t)= integral from 0 to 1 of ||u(x,t)||^2 dx
//SOLVE THE PDE ON A RING
double start = omp_get_wtime();
#pragma omp parallel default(none) shared(solution, energy, numThreads, std::cout) private(i, t, iBefore, iAfter)
{
#pragma omp master
numThreads = omp_get_num_threads();
for(t=0; t<NT-1; t++){
#pragma omp for schedule(static, 8) nowait
for(i=0; i<NX; i++){
iBefore = (i==0)?NX-2:i-1;
iAfter = (i==NX-1)?1:i+1;
solution[t+1][i][0]=solution[t][i][0] 
+ DT*(  -C*((solution[t][iAfter][0]-solution[t][iBefore][0])/(2*DX))
+ K*(solution[t][iAfter][0]-2*solution[t][i][0]+ solution[t][iBefore][0])/(DX*DX)  );
}
// COMPUTE THE ENERGY OF PREVOIUS TIME ITERATION
#pragma omp for schedule(auto) reduction(+:energy[t])
for(i=0; i<NX; i++) {
energy[t] += DX*solution[t][i][0]*solution[t][i][0];
}
}
}
std::cout << "numThreads: " <<numThreads << ". Elapsed Time: "<<(omp_get_wtime()-start)*1000 << std::endl;
return 0;
}

以及的性能

numThreads: 1. Elapsed Time: 9.65456
numThreads: 2. Elapsed Time: 9.1855
numThreads: 3. Elapsed Time: 9.85965
numThreads: 4. Elapsed Time: 8.9077
numThreads: 5. Elapsed Time: 15.5986
numThreads: 6. Elapsed Time: 15.5627
numThreads: 7. Elapsed Time: 16.204
numThreads: 8. Elapsed Time: 17.5612

分析

首先,您使用的粒度太小,使多线程无法非常高效。事实上,你的顺序时间是9.6毫秒,有999个时间步长。因此,每个时间步长大约需要9.6个我们,这是相当小的。

此外,内存访问效率低下:

  • 一方面,使用std::vector<std::vector<std::vector<double>>>在内部生成一个数组,该数组包含指向数组的指针,该数组则包含指向双精度数组的指针(均为动态分配的(。数组在内存中可能不连续,也可能排列不整齐。这会显著降低执行速度,因为处理器更难从内存中预取数据。考虑分配一个大数组而不是多个小数组(例如,一个大的扁平std::vector(
  • 另一方面,以这种方式使用填充会导致非常低效的内存访问模式。事实上,您只使用8的1倍,因此浪费了7/8的内存使用量(可能更多,因为std::vector可以分配额外的内存(。此外,由于添加了填充,一个读/写是不连续的,处理器很难预取数据,也很难有效地使用内存(因为读/写都是按缓存行执行的,即多个双精度标量(。考虑应用矩阵的填充行或块(而不是标量(

最后,使用大小为8的块的时间表似乎太小了。对于并行的for和reduce,这里只指定schedule(static)可能会更好(如果您使用nowait并且我认为您想要正确的结果,那么两者的时间表应该是相同和静态的(。

因此,您可能正在测量延迟和内存开销。

改进版

以下是具有最重要修复的已更正代码(忽略错误共享效果(:

#include <iostream>
#include <vector>
#include <cmath>
#include <omp.h>
const int NX = 500; //DOMAIN DISCRETIZATION
const int PAD = 8; //PADDING TO AVOID FALSE SHARING
const double DX = 1.0/(NX-1.0); //STEP IN SPACE
const double DT = 0.01*DX; //STEP IN TIME
const int NT = 1000; //MAX TIME ITERATIONS
const double C = 10.0; //CONVECTION VELOCITY
const double K = 0.01; //DIFFUSION COEFFICIENT
int main(int argc, char **argv) {
omp_set_num_threads(std::atoi(argv[1]));  //SET THE REQUIRED NUMBER OF THREADS
//INTIALING MEMORY --> USING A FLATTEN DOUBLE ARRAY
std::vector<double> solution(NT * NX);
for (int i=0; i<NX; i++){
solution[0*NX+i] = std::sin(i*DX*2*M_PI); //INITIAL CONDITION
}
int numThreads, i, t, iBefore, iAfter;
double energy[NT]{0.0}; //ENERGY of the solution --> e(t)= integral from 0 to 1 of ||u(x,t)||^2 dx
//SOLVE THE PDE ON A RING
double start = omp_get_wtime();
#pragma omp parallel default(none) shared(solution, energy, numThreads, std::cout) private(i, t, iBefore, iAfter)
{
#pragma omp master
numThreads = omp_get_num_threads();
for(t=0; t<NT-1; t++){
#pragma omp for schedule(static) nowait
for(i=0; i<NX; i++){
iBefore = (i==0)?NX-2:i-1;
iAfter = (i==NX-1)?1:i+1;
solution[(t+1)*NX+i]=solution[t*NX+i]
+ DT*(  -C*((solution[t*NX+iAfter]-solution[t*NX+iBefore])/(2*DX))
+ K*(solution[t*NX+iAfter]-2*solution[t*NX+i]+ solution[t*NX+iBefore])/(DX*DX)  );
}
// COMPUTE THE ENERGY OF PREVOIUS TIME ITERATION
#pragma omp for schedule(static) reduction(+:energy[t])
for(i=0; i<NX; i++) {
energy[t] += DX*solution[t*NX+i]*solution[t*NX+i];
}
}
}
std::cout << "numThreads: " <<numThreads << ". Elapsed Time: "<<(omp_get_wtime()-start)*1000 << std::endl;
return 0;
}

结果

在我的6核机器上(英特尔i5-9600KF(。我得到以下结果。

之前:

1 thread : 3.35 ms
2 threads: 2.90 ms
3 threads: 2.89 ms
4 threads: 2.83 ms
5 threads: 3.07 ms
6 threads: 2.90 ms

之后:

1 thread : 1.62 ms
2 threads: 1.03 ms
3 threads: 0.87 ms
4 threads: 0.95 ms
5 threads: 1.00 ms
6 threads: 1.16 ms

使用新版本,顺序时间要快得多,并且可以成功地扩展到3个内核。然后,同步开销变得很大,并降低了整体执行速度(请注意,每个时间步长持续的时间不到1 us,这非常小(。