张晓梅 ~ 第十五届全国科学计算与信息化会议暨高能物理核物理信息化论坛

Presentation on theme: "张晓梅 ~ 第十五届全国科学计算与信息化会议暨高能物理核物理信息化论坛"— Presentation transcript:

1 张晓梅 2011.7.4~2011.7.7 第十五届全国科学计算与信息化会议暨高能物理核物理信息化论坛
BESIII离线物理软件在64位升级中的若干问题 张晓梅 ~ 第十五届全国科学计算与信息化会议暨高能物理核物理信息化论坛

2 内容 BESIII离线物理软件 64位机的三种工作模式 BESIII离线软件的升级过程及遇到的主要问题 升级前后的软件性能比较 总结

3 BESIII实验 北京谱仪（BESIII）是北京正负电子对撞机(BEPCII) 上的大型通用谱仪
它主要用于τ－粲能区的物理研究如弱电相互作用研究，强相互作用和新物理的寻找等 BESIII离线软件（BOSS, BESIII Offline Software System)的主要任务是将BESIII探测器和模拟产生的原始数据进行处理，生成物理分析使用的DST数据，同时提供物理分析所需的工具 BESIII离线物理软件是 BESIII物理分析的前提和关键 它的精度和性能决定着 物理分析的结果和进程

4 BESIII离线软件（BOSS) 大型的高能物理软件系统 基于高能物理软件通用框架Gaudi，采用CMT配置管理工具
包含了sim, rec, ana, cal等数据处理模块 使用了30多个外部库 采用mysql, sqlite等数据库进行刻度和几何参数的读取 对于大型的物理软件来说，64位升级具有相当的难度 系统庞大且算法，外部支持软件系统复杂 精度要求高，测试和检查过程细致繁杂 30+ External Library(ROOT..) GAUDI BOSS CMT 几何DB 刻度DB Ana Rec Cal Gen Sim …

5 64位升级的意义和必要性 64位机已经是计算机发展的趋势 64位系统具有巨大的内存优势 升级到64位后将显著提升软件性能
高能物理实验的主流机型早已是x86-64 64位系统具有巨大的内存优势 32位寻址(232~4GB), 64位寻址(264~16EB) 计算中心Lustre服务在64位上成功解决死机问题 升级到64位后将显著提升软件性能 许多知名的高能物理软件移植后取得了很好的性能提升 ROOT升级后得到40%的性能提升, Pythia 21%的性能提升 对BESIII数据处理已经势在必行 系统软件，物理外部软件已经逐渐不再支持32位 32位的内存瓶颈日益凸显，高性能系统只能运行在64位 CERN farm已与2007年升至64位，意味着支持的高能物理软件库->64位

6 64位机的三种工作模式 传统模式（Legacy mode) 兼容模式（Compatibility mode）
32位应用程序运行在32位操作系统 64位CPU可以当成32位CPU使用 升级前IHEPCC farm工作结点的主要工作模式—传统模式 兼容模式（Compatibility mode） 32位应用程序运行在64位操作系统 32位应用程序无需重新编译就可以运行在该模式 兼容模式是传统模式与完全模式之间的过渡模式 完全模式（Native mode） 64位应用程序运行在64位操作系统 升级的目标模式，可充分发挥64位处理器的优势，包括内存和性能优势

7 BESIII离线软件的64位升级 第一阶段：传统模式 兼容模式（Compatibility mode）
同时不耽误系统升级64位，突破内存瓶颈 CERN实验在兼容模式上已有较长的时间（三年） 第二阶段：兼容模式完全模式（Native mode） 最终完成所有32位程序升级到64位 需要对32位程序做出调整和修改，重新编译 出现问题较多，升级时间长

8 BESIII离线软件的64位升级的五个步骤 以问题为导向，循环递进 分为五个步骤: 建立运行环境 编译BOSS Run-time检查
无现成规律可循 测试尽可能全面，尽量发现问题 分为五个步骤: 建立运行环境 编译BOSS Run-time检查 大规模压力测试检查 物理结果检查 性能评估和优化 内存和速率 运行环境 操作系统 编译工具 硬件 共享库和boss.exe 外部库 BOSS Run-time 物理结果 性能 编译 检查 优化 执行

9 升级过程的主要问题 编译错误 程序异常 结果差异 内存膨胀

10 编译错误 编译选项的改变 编译规则的改变 外库的改变: “m32” -- 兼容模式下GCC提供的32位应用程序的编译和链接选项
“fPIC” 位要求共享库编译成”Position Independent Code” 由于各种库编译模式不同，容易产生遗漏 编译规则的改变 64位GCC比较32位GCC在编译规则更为严谨 特别表现在变量和函数声明、类型转化的情况 Eg. <cmath> “ some coding assumptions are not valid any more” 外库的改变: 外库的升级引起库的位置，函数的改变 CMT的升级造成policy的变化

11 程序异常（一） Segment fault, 程序不正常执行和结束 LP32到LP64的变化
Long, pointer类型长度从32位变为64位 Eg. std::string::npos=unsigned long, ≠ unsigned int,当值为-1,可能导致判断语句改变方向 LP32 LP64 char 8 int 4*8 long 8*8 pointer double long double 12*8 16*8

12 程序异常（二） 数组和指针越界 Gaudi升级 导致segment fault 典型原因：
程序对特殊的事例未作足够的保护，产生不合理数值，使得指针指向不合理内存位置； 数组没有做正确的定义,造成使用时越界 值得注意是这些问题在32位模式下没有发生程序异常，内存分配方式不同？ Gaudi升级 基础函数的使用发生变化 Eg. 不能获得正确的服务指针，不能正常释放组件对象

13 结果差异（一） 在两个阶段升级的物理检查中，都看到了差异 传统模式到兼容模式的升级阶段 有些差异是错误引起的，可以避免
有些差异却是32位和64位系统本身的差异带来的精度变化，不可避免 统计差异和数值差异 统计差异是不允许的，这种差异可能导致物理结果的不一致 数值差异需要尽量避免 传统模式到兼容模式的升级阶段 理论上是物理结果可以保证无差异 错误引起的统计差异： 变量未做初始化，函数的返回值没有正确设定 数值差异：模拟的基础软件Geant4产生的差异 随着Geant4不断完善，差异将被消除

14 结果差异（二） 兼容模式到完全模式的升级阶段 LP32->LP64的变化引起的错误产生的差异
Eg. Geant4随机数产生函数产生的整数计算结果变化，原因是其中的long变量没有正确使用 浮点计算模式和ABI的变化使得浮点计算的精度发生改变，不可避免 由于浮点计算位数有限，中间寄存器的位数或者计算顺序的变化的细微差别，可能造成浮点计算结果的变化 32位采用x87指令集，64位采用SSE指令集

15 内存膨胀 64位BOSS与32位BOSS的内存比较： 64位BOSS的内存使用要比32位BOSS增长一倍
32位中不明显内存泄露在64位被放大 主要原因： LP32到LP64的转换，使得数据类型(long, pointer, size_t)占用空间增大 数据结构，共享库进行对齐和填充的空间增大 对堆内的对象管理所用的空间增加 优化BESIII离线软件内存使用和尽量减少内存泄露在64位上更显重要 RSS(MB) simu simu-reco real-reco 64-bit 605.8 534.8 456.0 32-bit 384.7 388.2 320.9 comparison ~57.5% ~37.8% ~42.1%

16 性能比较 模拟，重建和分析过程对于真实和模拟数据的事例处理率(Event/s) 传统模式和兼容模式： 没有差异 传统模式和完全模式
模拟提高了13%，重建和分析提高了50% 主要得益于64位更好的体系结构：更多更大的寄存器优势，内存优势，更为高效的函数调用机制，fPIC效率等 Application (sec/event) simu simu-reco real-reco simu-ana real-ana 64-bit 32-bit improvement ~13% ~50% ~48% ~61%

17 总结 BESIII离线物理软件已经成功升级到64位 第一个64位官方版本BOSS6.6.0于今年5月正式发布
重建和分析的事例处理率提高了一倍 第一个64位官方版本BOSS6.6.0于今年5月正式发布 同时32位的BOSS版本将以兼容模式存在，与64位BOSS并存一段时间，保证不影响物理学家的分析进程 内存使用优化和性能优化将成为下一步研究的重点 在64位下BOSS内存使用成倍增加

18 Thank you!