我目前正在实现一种解决背包问题的动态规划算法。因此我的代码有两个 for 循环,一个外循环和一个内循环。
从逻辑的角度来看,我可以并行化内部 for 循环,因为那里的计算彼此独立。由于依赖关系,外部 for 循环无法并行化。
所以这是我的第一种方法:
for(int i=1; i < itemRows; i++){
int itemsIndex = i-1;
int itemWeight = integerItems[itemsIndex].weight;
int itemWorth = integerItems[itemsIndex].worth;
#pragma omp parallel for if(weightColumns > THRESHOLD)
for(int c=1; c < weightColumns; c++){
if(c < itemWeight){
table[i][c] = table[i-1][c];
}else{
int worthOfNotUsingItem = table[i-1][c];
int worthOfUsingItem = itemWorth + table[i-1][c-itemWeight];
table[i][c] = worthOfNotUsingItem < worthOfUsingItem ? worthOfUsingItem : worthOfNotUsingItem;
}
}
}
代码运行良好,算法正确解决了问题。 然后我在考虑优化它,因为我不确定 OpenMP 的线程管理是如何工作的。我想防止在每次迭代期间对线程进行不必要的初始化,因此我在外部循环周围放置了一个外部并行 block 。
第二种方法:
#pragma omp parallel if(weightColumns > THRESHOLD)
{
for(int i=1; i < itemRows; i++){
int itemsIndex = i-1;
int itemWeight = integerItems[itemsIndex].weight;
int itemWorth = integerItems[itemsIndex].worth;
#pragma omp for
for(int c=1; c < weightColumns; c++){
if(c < itemWeight){
table[i][c] = table[i-1][c];
}else{
int worthOfNotUsingItem = table[i-1][c];
int worthOfUsingItem = itemWorth + table[i-1][c-itemWeight];
table[i][c] = worthOfNotUsingItem < worthOfUsingItem ? worthOfUsingItem : worthOfNotUsingItem;
}
}
}
}
这有一个不需要的副作用:并行 block 内的所有内容现在都将执行 n 次,其中 n 是可用内核的数量。我已经尝试使用 pragmas single
和 critical
来强制在一个线程中执行外部 for 循环,但是我无法通过多个线程计算内部循环除非我打开一个新的并行 block (但那样不会提高速度)。不过没关系,因为好处是:这不会影响结果。问题依然正确解决。
现在奇怪的是:第二种方法比第一种方法更快!
这怎么可能?我的意思是,尽管外部 for 循环计算了 n 次(并行)并且内部 for 循环在 n 个核心之间分布了 n 次,但它比第一种方法更快,后者只计算一次外部循环并将工作量分配给内部 for 循环均匀。
起初我在想:“嗯,是的,这可能是因为线程管理”,但后来我读到 OpenMP 池化了实例化线程,这与我的假设背道而驰。然后我禁用了编译器优化(编译器标志 -O0)以检查它是否与此有关。但这并不影响测量。
你们中的任何人都可以对此有更多的了解吗?
解决包含 7500 个元素且最大容量为 45000 的背包问题的测量时间(创建一个 7500x45000 的矩阵,这远远超过了代码中使用的 THRESHOLD 变量):
- 方法 1:~0.88s
- 方法 2:~0.52s
提前致谢
花花公子
编辑:
更复杂问题的度量: 向问题添加了 2500 个项目(从 7500 到 10000)(由于内存原因,目前无法处理更复杂的问题)。
- 方法 1:~1.19s
- 方法 2:~0.71s
编辑 2: 我误会了编译器优化。这不影响测量。至少我无法重现我之前测量的差异。我根据这个编辑了问题文本。
最佳答案
让我们首先考虑一下您的代码在做什么。本质上,您的代码正在转换一个矩阵(二维数组),其中行的值取决于前一行,但列的值独立于其他列。让我选择一个更简单的例子
for(int i=1; i<n; i++) {
for(int j=0; j<n; j++) {
a[i*n+j] += a[(i-1)*n+j];
}
}
并行化的一种方法是像这样交换循环
方法一:
#pragma omp parallel for
for(int j=0; j<n; j++) {
for(int i=1; i<n; i++) {
a[i*n+j] += a[(i-1)*n+j];
}
}
使用此方法,每个线程运行内循环的 i
的所有 n-1
次迭代,但仅运行 的
。这有效地并行处理了列 strip 。但是,这种方法对缓存非常不友好。n/nthreads
次迭代>j
另一种可能性是只并行化内部循环。
方法二:
for(int i=1; i<n; i++) {
#pragma omp parallel for
for(int j=0; j<n; j++) {
a[i*n+j] += a[(i-1)*n+j];
}
}
这实质上是并行处理单行中的列,但每一行都是按顺序处理的。 i
的值仅由主线程运行。
另一种并行处理列但按顺序处理每一行的方法是:
方法三:
#pragma omp parallel
for(int i=1; i<n; i++) {
#pragma omp for
for(int j=0; j<n; j++) {
a[i*n+j] += a[(i-1)*n+j];
}
}
在这种方法中,与方法 1 一样,每个线程在 i
上运行所有 n-1
迭代。但是,此方法在内部循环之后有一个隐式屏障,这会导致每个线程暂停,直到所有线程都完成一行,从而使此方法对每一行都是顺序的,就像方法 2 一样。
最好的解决方案是像方法 1 一样并行处理列 strip ,但仍然对缓存友好。这可以使用 nowait
子句来实现。
方法四:
#pragma omp parallel
for(int i=1; i<n; i++) {
#pragma omp for nowait
for(int j=0; j<n; j++) {
a[i*n+j] += a[(i-1)*n+j];
}
}
在我的测试中,nowait
子句没有太大区别。这可能是因为负载是均匀的(这就是为什么在这种情况下静态调度是理想的)。如果负载更少,甚至 nowait
可能会产生更大的不同。
以下是我的四核 IVB 系统 GCC 4.9.2 上 n=3000
的时间(以秒为单位):
method 1: 3.00
method 2: 0.26
method 3: 0.21
method 4: 0.21
此测试可能受内存带宽限制,因此我本可以使用更多计算选择更好的情况,但差异仍然足够大。为了消除由于创建线程池而造成的偏差,我运行了其中一种方法,但没有先对其进行计时。
从时间上可以清楚地看出方法 1 是多么不缓存友好。很明显,方法 3 比方法 2 更快,而且 nowait
在这种情况下几乎没有影响。
由于方法 2 和方法 3 都并行处理一行中的列,但按顺序处理行,因此人们可能期望它们的时间相同。那么它们为什么不同呢?让我做一些观察:
由于线程池的存在,不会为方法 2 的外循环的每次迭代创建和销毁线程,因此我不清楚额外的开销是多少。请注意,OpenMP 没有提及线程池。这是每个编译器实现的东西。
方法 3 和方法 2 之间唯一的其他区别是在方法 2 中只有主线程处理
i
而在方法 3 中每个线程处理一个私有(private)的i
。但这对我来说似乎太微不足道了,无法解释这些方法之间的显着差异,因为方法 3 中的隐式屏障导致它们无论如何都会同步,并且处理i
是一个增量和条件测试的问题。事实上,方法 3 并不比方法 4 慢,方法 4 并行处理整个列 strip ,这说明方法 2 中的额外开销全部在于
i< 的每次迭代离开和进入并行区域
所以我的结论是,要解释为什么方法 2 比方法 3 慢得多,需要查看线程池的实现。对于使用 pthreads 的 GCC,这可能可以通过创建线程池的玩具模型来解释,但我还没有足够的经验。
关于c++ - OpenMP - 嵌套 for 循环在外部循环之前并行时变得更快。为什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/31321071/