OpenMp并行提升时间为什么不是线性的？

最近在研究OpenMp，写了一段代码，如下：

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

#define THREAD_NUM 8
int main()
{
 clock_t start,finish;
int n=;

int sum;
start=clock();
for(int i=;i<n;i++)
{
 sum+=;
 sum-=;
}

finish=clock();
printf("Serial computation\n");
printf("time:%lf\n",(double)(finish-start)/CLOCKS_PER_SEC);

printf("Parallel computation\n");
start=clock();
#pragma omp parallel num_threads(THREAD_NUM)
{
 int nth=omp_get_num_threads();
 int me=omp_get_thread_num();
 int mysum=;
 clock_t t1,t2;

 t1=clock();
 for(int i=me;i<n;i+=nth)
 {
  mysum+=;
  mysum-=;
 }
 t2=clock();
 printf("time:%lf\t%d\n",(double)(t2-t1)/CLOCKS_PER_SEC,mysum);
}

finish=clock();
printf("Total time:%lf\n",(double)(finish-start)/CLOCKS_PER_SEC);

 return ;
}

输出结果：

Serial computation
time:0.356796
Parallel computation
time:0.154885
time:0.221016
time:0.284257
time:0.253218
time:0.296142
time:0.269889
time:0.312325
time:0.275955
Total time:0.322763

上面的结果很奇怪，程序开了8个线程，可是得到的结果却不是1/8，考虑到线程的创建等等开销，提升的幅度达不到8倍，但是也不至于就1.1倍左右啊;而且每个线程只做了计算的1/8次迭代，消耗的时间远远大于1/8的时间。

思考一下可能存在以下原因：

1) 线程中的printf这种函数并不是并行安全的，所以各个线程在最后快要结束的时候会争抢控制台资源，不过占用不了太多时间。

2) 线程的创建和撤销存在一定的消耗，不过个人觉得这部分也不会占用太多时间，如果这个结论成立，那么增加线程的计算时间，是不是可以提升幅度呢？

3) false sharing(参见我的上一篇博文)，目测并不是false sharing的原因。

4) 存在其他冲突的资源，导致了线程之间存在关联，并不能完全并行。

5) 代码中的for循环在执行时的问题。

对上面的几点疑问，逐个进行了探讨。

---

线程的创建核撤销的消耗

增加线程的计算时间，那么提升的幅度会不会增加呢？考虑到此，做了如下的实验，将代码中的n改成160000000，那么得到的运行结果如下：

Serial computation
time:0.640447
Parallel computation
time:0.319365
time:0.503179
time:0.579748
time:0.581418
time:0.629072
time:0.592573
time:0.634568
time:0.609349
Total time:0.646393

这次的效果更糟糕，而且总的并行时间是比串行的还要慢，再看看单个线程的时间，虽然计算了1/8的迭代，可是时间除了第一个线程使用原先1/2时间外，剩下的几乎等于串行的时间。从实验的结果上来看，增加一倍迭代次数后，单个线程消耗的时间大致也会提高一倍，因此线程的创建和撤销的因素基本可以忽略。一定是某个原因导致了计算时间的快慢。

---

false sharing

程序代码中并行的部分全是私有化的变量，甚至都没有将mysum累加到主线程中，不会发生false sharing，这一点可以排除。

---

for循环

for循环会不会出现猫腻呢？为此也做了以下的实验：

#include<stdio.h>
#include<stdlib.h>
#include<time.h>
int main()
{
 int n=;
 int sum=;
 clock_t start,finish;
 start=clock();
 for(int i=;i<n;i++)
  for(int j=;j<n;j++)
   {
      sum++;
      sum--;
   }
 finish=clock();
 printf("time1:%lf\n",(double)(finish-start)/CLOCKS_PER_SEC);

 start=clock();
 for(int i=;i<n/;i++)
  for(int j=;j<n*;j++)
   {
      sum++;
      sum--;
   }
 finish=clock();
 printf("time2:%lf\n",(double)(finish-start)/CLOCKS_PER_SEC);

 start=clock();
 for(int i=;i<n*;i++)
  for(int j=;j<n/;j++)
   {
      sum++;
      sum--;
   }
 finish=clock();
 printf("time3:%lf\n",(double)(finish-start)/CLOCKS_PER_SEC);

 start=clock();
  for(int j=;j<n*n;j++)
   {
      sum++;
      sum--;
   }
 finish=clock();
 printf("time4:%lf\n",(double)(finish-start)/CLOCKS_PER_SEC);

}

输出结果：

time1:0.431033
time2:0.377387
time3:0.383699
time4:0.372852

结果是循环相同的次数，单层是最快的，而外层和里层次数一样是最慢的，因为CPU 跨切循环层。

另外插一个题外话，for循环遍历不当也会引起false sharing，我们看下面的例子：

右边的循环之所以比左边的效率高，与程序访问的局部性和Cache命中率有关。数组在计算机中是行优先存储的，左边的循环中，依次访问的是变量a[0][0]，a[1][0]，a[2][0]，...，a[99][0]，a[0][1]，a[1][1]，a[2][1]，……，a[99][1]，……这实际上是按照列优先的原则在访问数组元素。如果Cache容量相对于数组容量而言不够大，考虑一个极端情况，假设Cache只有一个块，只能存储一行数据，则每访问一个元素就会发生一次Cache失效，就需要访问一次主存，读入一块数据，导致存储系统效率低下，明显影响操作延迟。而右边的循环采用的是行优先访问原则，与元素存储顺序一致。基于同样的假设，此时只有访问新一行的第一个数据时才发生Cache失效，通过访问主存读入一块连续的数据（恰为数组的一行），此后访问同行数据便可直接使用Cache中缓存的数据，直到访问下一行的第一个数据。Cache失效率降低了，整个存储系统的平均访问延迟降低了，显然程序执行效率较高。

言归正传，从for循环的实验中可以看出并不是计算时间的问题。

---

以上的几个方面都做了实验，都找不到问题所在，研究了几天了，姑且放在这吧。知道问题所在的，往告知，不甚感谢～～