c - 使用 #pragma parashare 在 OpenMP 中并行化嵌套循环

Question

我正在尝试并行化代码。我的代码如下所示 -

    #pragma omp parallel private(i,j,k)
    #pragma omp parallel for shared(A)
    for(k=0;k<100;<k++)
     for(i=1;i<1024;<i++)
      for(j=0;j<1024;<j++)
       A[i][j+1]=<< some expression involving elements of A[i-1][j-1] >>

执行此代码时，我从循环的串行执行中得到了不同的结果。我无法理解我做错了什么。

我也尝试过崩溃()

    #pragma omp parallel private(i,j,k)
    #pragma omp parallel for collapse(3) shared(A)
    for(k=0;k<100;<k++)
     for(i=1;i<1024;<i++)
      for(j=0;j<1024;<j++)
       A[i][j+1]=<< some expression involving elements of A[][] >>

我尝试的另一件事是在每个循环之前使用#pragma omp parallel for而不是collapse()。

我认为问题在于数据依赖性。知道如何在数据依赖的情况下并行化吗？

Answer 1

如果这确实是您的用例，只需对外部循环进行并行化，k，这应该足以满足您在常见架构上拥有的适度并行性。

如果您想要更多，则必须重新编写循环，以便拥有不具有依赖性的内部部分。在您的示例中，这相对容易，您必须通过“对角线”(外循环，顺序)进行处理，然后在对角线内部您将是独立的。

for (size_t d=0; d<nDiag(100); ++d) {
   size_t nPoints = somefunction(d);
#pragma omp parallel
   for (size_t p=0; p<nPoints; ++p) {
      size_t x = coX(p, d);
      size_t y = coY(p, d);
      ... your real code ...
   }

}

其中一部分可以自动完成，但我认为此类工具尚未在日常 OMP 中轻松实现。这是一个活跃的研究领域。

另请注意以下事项

• int 对于索引来说并不是一个好主意，特别是在访问矩阵时。如果您必须自己计算条目的绝对位置(并且您看到您可能在这里)，那么很容易溢出。 int 通常是 32 位宽，在这 32 位中，您甚至浪费了一位作为符号。在 C 中，对象大小通过 size_t 计算，大多数情况下为 64 位宽，并且在任何情况下都是平台设计者选择的正确类型。
• 将局部变量用于循环索引和其他临时变量，正如您所见，编写 OMP 编译指示变得更加容易。局部性是并行性的关键之一。正确地表达这一点对你自己和编译器都有帮助。