关于并行程序调试

大规模并行程序调试及优化

1 前言

从串行到并行,需要多考虑很多东西(并行体系结构、通信、负载均衡),有些事也变得更困难了,最典型的一个例子就是程序的调试
想象如下场景,我刚用MPI写了个程序,运行发现有问题,可能出现的错误种类有:1) 只有某个进程出现了错误; 2) 并行规模变大了才出现的错误; 3) 用Intel的MPI跑有问题但用MPICH又不出错; 4) 单进程没问题但多进程就不行了,可能与通信有关...
以上错误都是串行程序所没有的。那么,要如何定位并解决问题呢,天才的话可能扫一遍代码就能发现错在哪里,而身为庸才的我,当然是要进行并行程序的调试了~

于是开始用各种手段对付MPI:

2 有效且常见的方法

最容易想到的方法当然就是变量输出了,判断哪个变量可能有错误,coutprintfwrite使用一通,总能发现一些问题吧
缺点当然也很明显:

  1. 低效率,需要改变源代码并重新编译,大型项目可能很费时
  2. 存在许多不同类型的变量需要打印时,需要花费精力在输出格式控制上
  3. 调试目的不是为了找出错误、而是为了看懂别人的代码细节时,往往存在大量变量去理解,一个个打印出来实在太慢

3 gdb工具

说到linux下的调试怎么都离不开gdb,毕竟开源、功能也还齐全,对于并行程序来说,也不是不能用,只需要运行以下命令:

mpirun -np N xterm -e cgdb ./a.out

(我一般用cgdb作为GUI)这里xterm系统默认的字体主题实在没法看,可以自行做一些调整如下:

! 使用方式
! vim ~/.Xresources
! xrdb -merge ~/.Xresources
! xrdb -query
! xterm
xterm*faceName:             DejaVu Sans Mono:style=Book:antialias=true
xterm*faceNameDoublesize: WenQuanYi Micro Hei
!xterm*faceNameDoublesize:   Noto Sans CJK SC
xterm*faceSize: 11
xterm*renderFont:           true
xterm*cjk_width:            true
xterm*geometry:             80x25
xterm*dynamicColors:        true
xterm*utf8:                 2
xterm*eightBitInput:        true
xterm*saveLines:            2048
xterm*scrollKey:            true
xterm*scrollTtyOutput:      false
xterm*scrollBar:            true
xterm*rightScrollBar:       true
xterm*jumpScroll:           true
xterm*multiScroll:          true
xterm*toolBar:              false
xterm*Scrollbar*thickness:  10
xterm*Scrollbar*background: black
xterm*Scrollbar*foreground: gray90
xterm*termName:             xterm-256color
xterm*decTerminalID:        vt340
! https://askubuntu.com/questions/237942/how-does-copy-paste-work-with-xterm
xterm*selectToClipboard:    true
! https://futurile.net/2016/06/15/xterm-256color-themes-molokai-terminal-theme/
xterm*background:   rgb:1a/1a/1a
xterm*foreground:   rgb:d6/d6/d6
xterm*cursorColor:  rgb:d6/d6/d6
xterm*color0:       rgb:00/00/00
xterm*color1:       rgb:9e/18/28
xterm*color2:       rgb:00/88/00
xterm*color3:       rgb:96/8a/38
xterm*color4:       rgb:41/41/71
xterm*color5:       rgb:96/3c/59
xterm*color6:       rgb:41/81/79
xterm*color7:       rgb:be/be/be
xterm*color8:       rgb:66/66/66
xterm*color9:       rgb:cf/61/71
xterm*color10:      rgb:7c/bc/8c
xterm*color11:      rgb:ff/f7/96
xterm*color12:      rgb:41/86/be
xterm*color13:      rgb:cf/9e/be
xterm*color14:      rgb:71/be/be
xterm*color15:      rgb:ff/ff/ff

我之前用gdb对并行程序调试了一段时间,感觉还是很不方便,最多只能到3个进程,不然窗口切换来切换去,进程间的同步就已经够折腾了,再加上还要一个命令一个命令的输出各进程的变量,实在是很低效。

感受一下gdb调试mpi的恐惧吧

4 专业并行调试软件

之前也搜过有没有开源的并行调试工具,结果没有找到一个满足我的使用需求的。听说eclipse也能调试MPI程序,但我没有具体操作过,毕竟不用这个IDE

现在国际上的商用并行程序调试软件基本上就2家:

  1. TotalView
  2. Arm DDT

文章开头的PPT对Arm DDT有简要的介绍,中科院软件研究所好像买过,不过自从贸易战之后不知道现在还接不接受国内客户。TotalView我去官网逛了几圈竟然发现购买价格它都不直接告诉你,还需要发邮件咨询;请求试用版后邮件还要我告知各种信息,我嫌麻烦就懒得回了。Arm DDT倒是很有效率,请求试用后5分钟之内license就已经发到邮箱了,经过几天的使用,唯一的感受就是:
太好用了吧!!!
直接在软件里打开可执行文件、设定进程数,就可以开始debug了,不同进程的数据点一下就能切换,在右边窗口直观地显示出来;设置的断点可以保存成文件下次直接导入...

强大的Arm DDT

正式版还是挺贵的,光DDT这一个模块就220美元一年,但我竟然还有点忍不住想买,因为用过之后再和用gdb的调试方法一对比,差距还是太悬殊了...

可惜国内也没有发现在做这种并行调试工具的,毕竟这么多超算中心,还是很缺这种工具的吧。

Author: zcp
Reprint policy: All articles in this blog are used except for special statements CC BY 4.0 reprint polocy. If reproduced, please indicate source zcp !
评论
Valine utteranc.es
 Previous
《死月妖花~四月八日~》游玩思考记录1
1 前言上班之后基本上很少有时间玩这类游戏,之前也偶尔有粗略找过一些,没发现什么好的作品。直到上周翻番組的榜单时,一个叫做《死月妖花 (しがつようか) ~四月八日~》的同人作品映入我的眼中。给我的第一印象是:看起来像是我喜欢的类型
Next 
稀疏线性方程组直接求解库学习
1 前言最近正在入门代数求解相关领域,简单来说就是研究$Ax=b$如何求解,只不过这里的$A$是一个大型(上亿阶)稀疏(大量0元素)矩阵。虽然工程实际中用得最多的是迭代法,这里还是先介绍直接求解的相关库 首先,推荐Xiaoye
  TOC