c – OpenMP num_threads(1)比没有OpenMP执行得更快

前端之家收集整理的这篇文章主要介绍了c – OpenMP num_threads(1)比没有OpenMP执行得更快前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我在各种情况下运行我的代码,导致我认为是奇怪的行为.我的测试是使用HT的双核Intel Xeon处理器.

没有OpenMP’#pragma’语句,总运行时间= 507秒

使用OpenMP’#pragma’语句指定1个内核,总运行时= 117秒

使用OpenMP’#pragma’语句指定2个内核,总运行时间= 150秒

使用OpenMP’#pragma’语句指定3个内核,总运行时间= 157秒

使用OpenMP’#pragma’语句指定4个核心,总​​运行时间= 144秒

我想我不知道为什么注释我的openmp行使程序在1个线程之间没有openmp和1个线程WITH openmp的速度减慢.

我正在改变的是:

//#pragma omp parallel for shared(segs) private(i,j,p_hough) num_threads(1) schedule(guided)

and...

#pragma omp parallel for shared(segs) private(i,p_hough) num_threads(1,2,3,4) schedule(guided)

无论如何,如果任何人有任何想法为什么会发生这种情况,请让我知道!

感谢任何帮助,

布雷特

编辑:我会在这里解释一些评论

我使用num_threads(1),num_threads(2)等.

经进一步调查,结果是根据代码中是否包含“计划(指导)”行,我的结果不一致.

– 当我使用计划(指导)行时,我生成最快的解决方案,不管线程数.
– 当我使用默认调度程序时,我的结果显着变慢和不同的值
– 随着线程增加,时间表(指导)的改进不会得到改善
– 没有计划(指导)我增加线程获得改进

我想我没有找到一个足够的描述,对于什么时间表(指导)对我来说,我明白,它试图拆分循环,以便最时间密集的迭代首先发生,这应该有最少的影响一个线程等待其他人完成迭代的时间量.

看来对于我的〜900迭代循环,当我使用schedule(引导),我只处理〜200次迭代,在那里没有进度(指导)我正在处理所有的900次迭代.有什么想法吗?

解决方法

OpenMP具有重要的同步开销.我发现,除非你有一个很大的循环来做很多工作,而且没有进行循环内同步,那么通常不值得使用OpenMP.

我认为当将线程数设置为1(1)时,OpenMP只需对执行循环的OpenMP过程执行一个过程调用,因此开销最小,性能基本上与非OpenMP情况相同.

否则,我认为OpenMP设置一些信号量,等待“工作者”线程唤醒,同步他们访问数据结构,告诉他们要设置什么循环参数,然后调用执行该工作的例程,当他们完成大部分他们再次发信号给主线程.这个同步必须发生在一个线程所做的每个工作块上,并且同步成本是不平凡的.

使用STATIC调度选项可以帮助减少调度/同步开销,特别是如果循环迭代次数相对于内核数量较大.

原文链接:https://www.f2er.com/c/113541.html

猜你在找的C&C++相关文章