Multithreading OpenMP并行数值积分（求和）性能

我最近开始学习并行编码，我还处于起步阶段，所以我想尝试一些非常简单的编码。由于执行并行数值积分符合我的兴趣，我从一个简单的求和Fortran代码开始：

program par_hello_world

use omp_lib

implicit none

integer, parameter:: bign = 1000000000
integer:: i

double precision:: start, finish, start1, finish1, a

a = 0

call cpu_time(start)

!$OMP PARALLEL num_threads(8)

  !$OMP DO REDUCTION(+:a)

    do i = 1,bign


      a = a + sqrt(1.0**5)

    end do

  !$OMP END DO

!$OMP END PARALLEL

call cpu_time(finish)

print*, 'parallel result:'

print*, a

print*, (finish-start)


a=0

call cpu_time(start1)

do i = 1,bign

  a = a + sqrt(1.0**5)

end do

call cpu_time(finish1)

print*, 'sequential result:'

print*, a

print*, (finish1-start1)

end program

代码基本上模拟了一个求和，我使用了奇怪的表达式sqrt1.0**5来计算时间，如果我只使用1，计算时间非常小，以至于我无法将顺序代码与并行代码进行比较。 我试图通过使用缩减条款来避免竞争条件

但是我得到了非常奇怪的时间结果：

如果我把线程数从2个增加到16个，我的计算时间并没有减少，但不知何故，我甚至得到了增加。 令人难以置信的是，顺序代码似乎也受到线程数选择的影响，我真的不明白为什么！特别是，如果我增加线程数，它会被提升。 我得到了变量a的正确结果

---

我想我在某个地方做错了什么，但我对此一无所知……

嗨，谢谢。通过提高可读性，您的意思是将代码放在代码格式中？您的计算可能微不足道，因此值得并行化—您只是添加了一个常量。sqrt1.0**5是在编译时计算的。@VladimirF实际上do循环的计算时间大约为2秒。。。另外，我真的无法解释为什么当我改变线程的数量时，顺序计算时间也会改变…@VladimirF谢谢你，总之，当我并行化一个数值积分时，我应该期望计算时间的减少与1/Np成比例，其中Np是处理器的数量吗？哦，是的！为什么我没有注意到？忘记你刚才的时间。使用系统时钟或omp获取时间。这个问题已经在这里多次提出。