在visual studio中运行OpenMP并行程序，设置的线程数NUM_THREADS与系统CPU线程数啥关系

Posted 2023-05-06

比如说，我用omp_get_max_threads得到的最大线程数是4，但是我在设置并行部分的线程数NUM_THREADS的时候，就算是大于4，好像也还是有效果的。
不太明白其中什么原理……

在这里，先回顾一下OpenMP的parallel并行区域线程数量的确定，对于一个并行区域，有一个team的线程去执行，那么该分配多少个线程去执行呢？

OpenMP的遇到parallel指令后创建的线程team的数量由如下过程决定：
1. if子句的结果
2. num_threads的设置
3. omp_set_num_threads()库函数的设置
4. OMP_NUM_THREADS环境变量的设置
5. 编译器默认实现（一般而言，默认实现的是总线程数等于处理器的核心数）
（查看更多信息）

2、3、4优先级依次降低的，也就是前面的设置可以覆盖后面的设置，当然也是相对而言，num_threads子句只会影响当前的并行区域，而omp_set_num_threads对OMP_NUM_THREADS环境变量的覆盖是在整个程序运行期间全局的。
（2）几个容易混淆的OpenMP函数
1. omp_get_thread_num
获取线程的num，即ID。这里的ID是OpenMP的team内的ID，在OpenMP中，一个team内的线程的ID是俺顺序排列的，0、1、2...
说明：此函数在并行区域外或者并行区域内都可以调用。在并行区域外，获取的是master线程的ID，即为0。在并行区域内，每次执行到此函数，获取的是当前执行线程的ID。 参考技术A （1）不写，或者超出最大数，则都用最大数。
（2）并行的原则，就是要留意，别把系统资源锁死了，得不偿失，反而比单线程耗费更多时间。
（3）算法，特别是循环设计得当，可以取得接近线程倍数的提升。追问

谢谢，大致了解了。
但是我把NUM_THREADS设置到50的时候（max是4），运行时间比4的时候缩短了一般（我知道我这个做法很搞笑……），这是什么原因呢？

追答

这就不太 了解了。建议在release模式下编译。

追问

好的，谢谢啦。

本回答被提问者采纳

Visual Studio 2013 OMP 发布模式

【中文标题】Visual Studio 2013 OMP 发布模式

【英文标题】：Visual Studio 2013 OMP release mode

【发布时间】：2015-06-07 05:54:51

【问题描述】：

我正在尝试在 Visual Studio 2013 中使用 OpenMP。

它在调试模式下运行良好，并且性能大幅提升，但是当我切换到发布模式时，我在激活 OpenMP 的情况下得到最差的结果。

在发布模式下，打印线程号将始终为 0。

  printf("%d\n", omp_get_thread_num());

很明显我的问题是：OpenMP 是否在发布模式下工作？ There is StackOverlfow 上已经有一个问题，但没有人回答

【参考方案1】：

我用 MSVC2013 社区版做了一个小测试，它在发布时也能完美运行。

问题的可能原因是某些编译选项取决于所选的构建模式。因此，如果您在调试模式下设置了一些选项，例如/openmp，则必须确保在切换到发布模式后再次设置它们：

这里有一个小测试来证明它有效：

const int size = 2048;
double mytable[size];
std::map<int, int> t;

#pragma omp parallel for   
for(int n = 0; n < size; ++n) 
    double angle = 2 * 3.1415 * n / size; 
    mytable[n] = std::sin(angle) - std::pow(std::cos(angle), 2.0);
    t[omp_get_thread_num()]++; 

std::cout << "Number of elements processed per thread:"<<std::endl; 
for(auto &x : t)
    std::cout<< x.first<<": "<< x.second<<std::endl; 
std::cout << "Done" << std::endl;

【讨论】：

是的，我在 Debug 和 Release 上做了同样的配置。但是在那之后我重新启动了 VS 并且发布配置消失了，不得不再次这样做。现在它起作用了。感谢您的回答：D