学习使用mpiP工具
- mpiP工具使用方法
- AMG编译和操作过程
- mpiP对AMG的分析结果
- 简单分析和理解分析结果
- 小结
mpiP工具使用方法
下载mpiP并查看其UserGuide。得知mpiP需要依靠几个库：
- libunwind : 用于收集和调用栈信息
- binutils : 用来解析程序地址到源代码行的信息
依赖库安装后，相应配置mpiP安装选项(依赖库路径、编译器、编译选项等。)，然后按提示安装。
mpiP生成一个动态库libmpiP.so，它相对简单，不需要重编程序。但为了获得正确的源文件和行号信息，最好使用它-g重编选项。两种使用方法。
- 将mpiP库与可执行文件链接起来。如果链接命令包含MPI库，要将mpiP库排序到MPI库之前，如
-l mpiP -lmpi - 运行时设置
LD_PRELOAD加载环境变量mpiP库
mpiP通过打开它们来收集相应的信息，为用户提供一系列运行选项。主要用途列出如下：
| 选项 | 作用 |
|---|---|
| -k n | 设置调用栈回溯深度(默认1) |
| -o | 初始化时关闭profiling，在希望profiling特定代码段通过MPI_Pcontrol()打开 |
| -p | 报告包括点对点通信的信息大小和通信子 |
| -y | 报告包括集合通信的消息大小和通信子 |
这些选项通过环境变量MPIP如：export MPIP="-t 10.0 -k 2" (bash)。
AMG编译和操作过程
在候选程序中选择AMG（https://github.com/LLNL/AMG）进行测试。clone下来后，按照README编译。注意几个编译选项，打开-DHYPRE_USING_PERSISTENT_COMM来使用MPI重复非阻塞通信可以提高性能，打开它-DHYPRE_HOPSCOTCH来提高OpenMP优化。它还提供-DHYPRE_PROFILE做一些非常简单的时间表(具体的时间表见seq_mv/HYPRE_seq_mv.h文件里的HYPRE_TimerID枚举类型需要在测试程序的最后手动写文件)，但这里没用。
需要修改编译Makefile.include中的INCLUDE_CFLAGS，加上-g同时修改选项INCLUDE_LFLAGS，加上-lmpip选项。
编译过程：依次进入子目录utilities，krylov，IJ_mv，parcsr_ls，parcsr_mv，seq_mv，编译每个源文件，生成相应的静态库*.a，最后进入test目录编译和链接测试程序。过程如图所示： 
在docs/amg.README可以看出，测试程序提供了两个问题的解决方案和参数的设置，所以我们只操作第一个。单节点打开128个过程，每个过程计算120x120x网格数据120，工艺布局4x4x8。
salloc -N 1 --exclusive --ntasks-per-node 128 mpirun --map-by slot:PE=1 --bind-to core amg -problem 1 -P 4 4 8 -n 120 120 120 -printallstats 如下所示(从左到右):
|
|
|
|
|
简单地说，这个程序包括问题的建立（Laplace方程离散后获得的27点网格矩阵)和问题解决(以代数多网格为预条件子的共轭梯度算法)。代数多网格（AMG）需要一个setup过程。在上述程序输出中，也简单地计时。
第一张图显示了稀疏矩阵A和右端向量的建立过程和耗时，第二张图显示了自动生成代数多网格的结构信息（每层的算子复杂性和稀疏度等），第三张图显示了层之间的插值矩阵信息和整个setup第四张图显示了共轭梯度法迭代过程中每个迭代步的残差和求解过程的耗时。
mpiP对AMG的分析结果
设置环境变量MPIP="-k5,-e,-y,-p"，在程序结束时输出一个mpiP记录文件。
打开可以看到几个部分。首先，记录程序运行的每个信息MPI过程分布： 第二部分记录了每个过程的花朵MPI相关函数上的时间占总时间比例:
可见通信负载不是很平衡，最小通信耗时的过程只有最大的一半左右。
第三部分展示了每一个MPI每个函数调用的信息ID调用相应的位置(相同的MPI函数出现在不同的地方，有不同的ID，如下图的Waitall），调用栈回溯到5层，所以每个都有ID重复出现5次，Lev更大的是调用器，每个函数都有源文件和行数。
如果程序使用的过程很多，通信模式复杂，这部分会很大。本次运行有47733条记录。
第四部分记录了前20个总耗时MPI函数调用。在这里site对应上一部分ID，本项对应的调用位置可以相应判断。 类似的记录包括发送的消息的总大小、次数和平均大小。根据消息总大小显示前20名。 由于打开了-y选项的下一部分显示了集合通信的总耗时、通信子尺寸和数据尺寸。可以看出，该程序只涉及四个集合通信。但我不知道为什么，这里没有site，不知道如何找到相应的调用位置。 由于打开了-p下一部分显示了点对点通信的通信子大小、消息大小等，MPI_Sent %似乎意味着调用占发送消息的总比例，但没有显示site。 最后一部分是每个调用位置的统计信息。第一部分是时间信息，包括操作时间的最大、最小值和平均值，以及调用位置在过程中耗时MPI总时间和整个程序时间的比例（Rank列中的星号代表该调用位置的累加的信息)。这部分的排序是按字母序的，a开头的Allreduce在前。 然后是通信信息大小的统计。
简单分析和理解分析结果
mpiP通信特征只能简单测量，大致可以从以上结果来判断:
- 程序中的通信主要是点对点通信
ISend发送消息的比例很高，每个位置的调用次数很多，通信消息的大小也很大；对使用的异步接收的Waiall说明是重复的非阻塞通信，且耗时占比很高- 集合通信的类型较少，耗时占比小，消息大小也很小
- 最耗时的点对点通信（即程序中的update halo操作），消息大小都在5.5 KB左右
- 通信负载很不均衡，MPI时间的min/max只有50%左右
- 程序的通信热点所在的路径包含了函数
hypre_ParCSRMatrixMatvecOutOfPlace，因为在调用位置的栈回溯中大量出现该函数（但仅通过通信特征来明确程序热点似乎有点不足，虽然它确实就是程序最耗时的部分）
小结
综合来看，要对一个程序进行性能分析，包括全面的计算、访存和通信，得需要多种的分析工具。光靠一种有点难以全面评估。而mpiP给出的信息只能覆盖通信特征，且缺乏直观，尤其在大规模进程数时，得到的callsite statistics非常庞大，需要用户自己通过site ID去找最耗时的通信调用对应在哪个地方。虽然通过mpiP的MPI_Pcontrol()可以实现任意具体代码段的分析，能减小输出的文件的规模，便于针对性的分析，但这就需要用户对程序代码本身有理解了才能在代码里添加MPI_Pcontrol()的控制。而且配合MPI_Pcontrol()启用-o选项后，不知道为什么，输出的文件里就没有具体通信调用处的通信子大小、消息大小等信息了。