count2=1 count2=10 count2=100 count2=1000
processors time/speedup,1 time/speedup,10 time/speedup,100 time/speedup,1000
1 1.59 1 3.04 1 8.13 1 50.79 1
2 1.32 1.204545 1.708 1.779859 4.23 1.921986 25.53 1.989424
4 0.966 1.645963 1.095 2.776256 2.26 3.597345 12.79 3.971071
8 0.8 1.9875 0.98 3.102041 1.15 7.069565 6.41 7.923557
12 0.797 1.994981 0.83 3.662651 0.98 8.295918 4.28 11.86682
16 0.85 1.870588 0.88 3.454545 0.86 9.453488 3.22 15.77329
24 0.82 1.939024 0.94 3.234043 0.89 9.134831 2.16 23.51389
30 0.835 1.904192 0.88 3.454545 0.85 9.564706 1.76 28.85795
36 1.015 1.566502 0.85 3.576471 0.83 9.795181 1.47 34.55102
!DEC$ if defined(OMP_test)
!$OMP PARALLEL DO PRIVATE(i,j,k,ii)
!DEC$ endif
DO nc= 1,count
i= index(nc,1)
j= index(nc,2)
k= index(nc,3)
DO ii = 1,count2
xc(nc) = i+j+k+ii
yc(nc) = i*j*k+ii
zc(nc) = i+j+k-ii
END DO
END DO
!DEC$ if defined (OMP_test)
!$OMP END PARALLEL DO
!DEC$ endif
count的值为10 ^ 6,count2在1到36个共享内存核心上测试了1,10,100,1000。我想知道为什么当count2为1,10或100(几个核心之后)时加速几乎可以忽略不计,然后当计数为1000(直到36个核心)时几乎是理想的。我写的所有应用程序都没有在do循环中进行大量计算,导致8核之后的加速可以忽略不计。
答案 0 :(得分:2)
所以这正是我所期待的,据我所知,你也是如此:
我写的所有应用程序都没有在do循环中进行大量计算,导致8核之后的加速可以忽略不计。
让我们采用这个计算最简单有意义的模型,如Amdahl's Law所述,其中花费的总时间是一些不变的串行开销(比如,fork / join)加上可以做的工作有效地并行化,这在很大程度上由count2
参数控制。所以我们有一些看起来像
时间(p)= a + b(alpha + count2)/ p
或
cpu_time(p)= p * time(p)= a p + b alpha + b count2
其中a是开销,b *(alpha + count2)是循环内可并行化工作量。
因此,我们可以轻松地适应这一点,并找到类似以下内容:
对于最大数量的处理器而言,这种适应性并不高,因为在最大数量的内核中可能存在内存争用(以及核心争用 - 超线程?),我们&#愚蠢地认为头顶不变。结果,高估了串行开销,并且低估了每个count2的工作量。但对于其他数据,它似乎与整体趋势一致。
所以我不确定你在这里想要什么 - 小count2
,你只有很少的CPU工作要做,因此在这个问题上投入更多的CPU不会加快速度起来。相反,您的内存带宽有限,而且需要采取哪些措施来提高性能。