简体   繁体   English

改变OpenMP并行区域的运行时间

[英]Varying run time of an OpenMP parallel region

Whenever I run this code it shows me different run-time took by the parallel section. 每当我运行此代码时,它就会向我显示并行部分花费的不同运行时间。 I tried with a constant number of threads according to my core but still the effort is futile. 我根据自己的核心尝试了恒定数量的线程,但仍然是徒劳的。 The program is to calculate the value of pi. 该程序将计算pi的值。 Compiled with gcc -fopenmp . gcc -fopenmp编译。

#include <stdio.h>
#include <omp.h>

static long num_steps = 100000; double step;
//double omp_get_wtime(void);

int main (){
      int i;
      double x,pi,max_threads,start,time;
      double sum=0.0;
      step = 1.0/(double) num_steps;
    //omp_set_num_threads(4);       
      omp_get_max_threads();
      start=omp_get_wtime();

    #pragma omp parallel
   {

    #pragma omp for reduction(+:sum) schedule(static) private(x) //reduction to get local copy
            for (i=0;i<num_steps;i++){
            x=(i+0.5)*step;
            sum += 4.0/(1.0+x*x);
            }
    //max_threads=omp_get_max_threads();
    }
time=omp_get_wtime()-start;
pi=step*sum;
printf("pi=(%f)\t run_time(%f)\n",pi,time);//,max_threads);
return 0;
 }

The code runs only a few milliseconds (on my system 2-6 ms), the time is being dominated overhead eg for thread creation. 该代码仅运行几毫秒(在我的系统上为2-6毫秒),该时间主要用于创建线程等开销。 The serial version runs <1 ms. 串行版本运行时间少于1毫秒。 It is normal for such short execution times to be very variable as it depends on the current state of the system, eg there is some 'warmup needed'. 通常如此短的执行时间会变化很大,这取决于系统的当前状态,例如,存在一些“需要预热”的情况。

In this case, just increase num_steps to get meaningful stable results. 在这种情况下,只需增加num_steps即可获得有意义的稳定结果。 Eg with num_steps = 1000000000 , 10 executions are all between 4.332 and 4.399 seconds on my system. 例如num_steps = 1000000000 ,我的系统上有10次执行全部在4.332和4.399秒之间。

Generally, if you do performance measurements, you should compile with the -O3 flag. 通常,如果进行性能测量,则应使用-O3标志进行编译。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM