Question

我有以下算法：

int hostMatch(long *comparisons)
{
    int i = -1;
    int lastI = textLength-patternLength;
    *comparisons=0;

    #pragma omp parallel for schedule(static, 1) num_threads(1)
    for (int k = 0; k <= lastI; k++)
    {
        int j;
        for (j = 0; j < patternLength; j++)
        {
            (*comparisons)++;
            if (textData[k+j] != patternData[j])
            {
                j = patternLength+1; //break    
            }
        }
        if (j == patternLength && k > i)
            i = k;
    }

    return i;
}

更改num_threads时，我会得到以下比较结果：

01 = 9949051000
02 = 4992868032
04 = 2504446034
08 = 1268943748
16 = 776868269
32 = 449834474
64 = 258963324

为什么比较次数不恒定？这很有趣，因为比较的数量减少了一半，线程数量增加了一倍。 (*comparisons)++是否存在某种竞争条件，如果变量正在使用，OMP只会跳过增量？

我目前的理解是 k 循环的迭代在线程中几乎均匀地分开。每次迭代都有一个私有整数 j 以及整数 k 的私有副本，以及一个非并行for循环，它会在比较之前添加到比较中。

Answer 1

围绕竞争条件的天真方式将操作声明为atomic update：

#pragma omp atomic update
(*comparisons)++;

请注意，这里的关键部分是不必要的，而且要贵得多。可以在任何具有标量类型的l值表达式上对原始二进制或一元运算声明atomic update。

然而，这仍然不是最佳的，因为*comparisons的值需要一直在CPU缓存之间移动，并且执行昂贵的锁定指令。相反，你应该使用减少。为此你需要另一个局部变量，指针不会在这里工作。

int hostMatch(long *comparisons)
{
    int i = -1;
    int lastI = textLength-patternLength;
    long comparisons_tmp = 0;

    #pragma omp parallel for reduction(comparisons_tmp:+)
    for (int k = 0; k <= lastI; k++)
    {
        int j;
        for (j = 0; j < patternLength; j++)
        {
            comparisons_tmp++;
            if (textData[k+j] != patternData[j])
            {
                j = patternLength+1; //break    
            }
        }
        if (j == patternLength && k > i)
            i = k;
    }

    *comparisons = comparisons_tmp;

    return i;
}

P.S。 schedule(static, 1)似乎是个坏主意，因为这会导致textData上的内存访问模式效率低下。把它留下来让编译器去做吧。如果测量表明它没有有效工作，请给它一些更好的提示。

Answer 2

你自己说(*comparisons)++;有竞争条件。这是一个必须序列化的关键部分（我不认为（*指针）++是一个原子操作）。

所以基本上你用两个线程两次读取相同的值（即2），然后增加它（3）并将其写回。所以你得到3而不是4.你必须确保对并行化函数/循环的本地范围内的变量的操作不重叠。

OpenMP - 为什么比较次数会减少？

2 个答案: