我有一个可以并行化的 C++ 程序。我正在使用 Visual Studio 2010,32 位编译。
简而言之,程序的结构如下
#define num_iterations 64 //some number
struct result
{
//some stuff
}
result best_result=initial_bad_result;
for(i=0; i<many_times; i++)
{
result *results[num_iterations];
for(j=0; j<num_iterations; j++)
{
some_computations(results+j);
}
// update best_result;
}
由于每个 some_computations()
都是独立的(读取了一些全局变量,但没有修改全局变量)我并行化了内部 for
循环。
我的第一次尝试是使用 boost::thread,
thread_group group;
for(j=0; j<num_iterations; j++)
{
group.create_thread(boost::bind(&some_computation, this, result+j));
}
group.join_all();
结果不错,但我决定多尝试一下。
我尝试了 OpenMP 库
#pragma omp parallel for
for(j=0; j<num_iterations; j++)
{
some_computations(results+j);
}
结果比 boost::thread
的结果差。
然后我尝试了 ppl 库并使用了 parallel_for()
:
Concurrency::parallel_for(0,num_iterations, [=](int j) {
some_computations(results+j);
})
结果是最差的。
我发现这种行为非常令人惊讶。由于 OpenMP 和 ppl 是为并行化而设计的,因此我希望得到比 boost::thread
更好的结果。我错了吗?
为什么 boost::thread
给我更好的结果?
最佳答案
OpenMP 或 PPL 不会做悲观的事情。他们只是按照他们被告知的去做,但是当您尝试并行化循环时,您应该考虑一些事情。
没有看到你是如何实现这些东西的,很难说真正的原因是什么。
此外,如果每次迭代中的操作都依赖于同一循环中的任何其他迭代,那么这将产生争用,从而减慢速度。您还没有显示您的 some_operation
函数实际执行的操作,因此很难判断是否存在数据依赖性。
可以真正并行化的循环必须能够让每个迭代完全独立于所有其他迭代运行,并且在任何迭代中都不会访问共享内存。因此,最好是将内容写入局部变量,然后在最后复制。
并非所有循环都可以并行化,这在很大程度上取决于所完成工作的类型。
例如,有利于并行化的是在屏幕缓冲区的每个像素上完成的工作。每个像素完全独立于所有其他像素,因此,一个线程可以进行一次循环迭代并完成工作,而无需在迭代之间等待循环中的共享内存或数据依赖性。
此外,如果你有一个连续的数组,这个数组可能有一部分在缓存行中,如果你在线程 A 中编辑元素 5,然后在线程 B 中更改元素 6,你可能会发生缓存争用,这也会放慢速度,因为它们将驻留在同一缓存行中。一种称为虚假共享的现象。
在进行循环并行化时需要考虑很多方面。
关于c++ - 使用 boost::thread 的并行任务比使用 ppl 或 OpenMP 获得更好的性能,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15206446/