OpenMP 和没有 OpenMP 代码的 gprof 产生不同的平面轮廓

Question

在我的代码中成功实施 OpenMP 之后，我试图检查该实施对我的代码性能提高了多少，但是使用 gprof 它给了我完全不同的平面配置文件。下面是我调用所有子程序的主程序。

program main
  use my_module
  call inputf       !to read inputs from a file
! call echo         !to check if the inputs are read in correctly, but is muted
  call allocv       !to allocate dimension to all array variable
  call bathyf       !to read in the computational domain
  call inicon       !to setup initial conditions
  call comput       !computation from iteration 1 to n
  call deallv       !to deallocate all array variables
end program main

以下是串行和并行代码的 cpu_time 和 OMP_GET_WTIME()。 OpenMP 并行区域在 subroutine comput.

内

!serial code
CPU time elapsed =   260.5080 seconds.
!parallel code
CPU time elapsed =   153.3600 seconds.
OMP time elapsed =    49.3521 seconds.

下面是串行和并行代码的平面配置文件。

!Serial code
Flat profile:
Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls   s/call   s/call  name
 96.26    227.63   227.63        1   227.63   236.45  comput_
  3.60    236.13     8.50     2001     0.00     0.00  update_
  0.08    236.32     0.19     2000     0.00     0.00  openbc_
  0.05    236.45     0.13       41     0.00     0.00  output_
  0.01    236.47     0.02        1     0.02     0.02  bathyf_
  0.01    236.49     0.02        1     0.02     0.03  inicon_
  0.00    236.50     0.01        1     0.01     0.01  opwmax_
  0.00    236.50     0.00     1001     0.00     0.00  timser_
  0.00    236.50     0.00        2     0.00     0.00  timestamp_
  0.00    236.50     0.00        1     0.00     0.00  allocv_
  0.00    236.50     0.00        1     0.00     0.00  deallv_
  0.00    236.50     0.00        1     0.00     0.00  inputf_

!Parallel code
Flat profile:
Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls   s/call   s/call  name
 95.52     84.90    84.90                             openbc_
  1.68     86.39     1.49     2001     0.74     0.74  update_
  0.10     86.48     0.09       41     2.20     2.20  output_
  0.00     86.48     0.00     1001     0.00     0.00  timser_
  0.00     86.48     0.00        2     0.00     0.00  timestamp_
  0.00     86.48     0.00        1     0.00     0.00  allocv_
  0.00     86.48     0.00        1     0.00     0.00  bathyf_
  0.00     86.48     0.00        1     0.00     0.00  deallv_
  0.00     86.48     0.00        1     0.00     2.20  inicon_
  0.00     86.48     0.00        1     0.00     0.00  inputf_
  0.00     86.48     0.00        1     0.00     0.00  comput_
  0.00     86.48     0.00        1     0.00     0.00  opwmax_

subroutine update、openbc、output 和 timser 在 subroutine comput 中调用。如您所见，subroutine comput 假设花费最多的运行时间，但并行代码的平面配置文件显示并非如此。如果您需要其他信息，请告诉我。

Answer 1

This article 说：

One problem with gprof under certain kernels (such as Linux) is that it doesn’t behave correctly with multithreaded applications. It actually only profiles the main thread, which is quite useless.

本文还提供了一种变通方法，但由于您没有手动创建线程，而是使用 OpenMP（透明地创建线程），因此您必须对其进行修改以使其适合您。

您也可以选择能够使用并行程序的分析器。

Answer 2

gprof 不适合分析并行程序，因为它不了解 OpenMP 的复杂性。您应该改为使用 Score-P and Cube 的组合。前者是一个仪器框架，而后者是分层性能数据的可视化工具。两者都是开源项目。在商业方面，可以使用 Intel VTune Amplifier。

OpenMP 和没有 OpenMP 代码的 gprof 产生不同的平面轮廓

gprof on both OpenMP and without OpenMP codes produces different flat profile

openmp

gprof