admin管理员组文章数量:1567745
2024年6月23日发(作者:)
随计算机硬件和网络设备技术的进步和价格的降低,以及工业上对更精细的FE模型的
需求,MPP版LSDyna所点市场份额逐渐增加。LSTC公司的 Benson在关于DYNA
history的presentation中甚至预测今后几年MPP会逐渐取代PC,SMP版Dyna。
目前LSTC公司硬件合作厂商(IBM,HP,SGI,SUN,etc)都推出了商业化的LS-DYNA计算
Cluster,这些硬件厂商通常会投 入相当一部分人力和财力在平台方面做开发和优化,借
着与LSTC良好的合作关系,其平台上的MPP LS-DYNA加速比都能达到很理想的值。
网站给出了MPP DYNA 相关的两个Benchmark文件(一个单车前撞,一
个三车碰撞),并且专门收集用户在各种硬件平台上对这两个文件MPP LS-DYNA并行计
算的速度信息。其中不乏各硬件厂商提供且来测试的硬件平台信息,包括CPU速度,数目,
网络连接类型等。从这些信息多们大致可以比较 不同的DYNA版本,不同的CPU,不同
的网络连接类型对MPP计算速度的影响。
然而今天我要讨论的是自己搭建平台时需要注意的一些问题(前面的信息对我们会很
有指导意义)。商用平台固然好,但并不是都能轻易得到。有时候不得不自己组建,这时候
就得在选择配件时作好规划,免得最后达不到自己期望的并行效率(加速比)。
影响MPP并行效率的几个关键因素:
--网络连接
--选择的MPI和执行块
--模型的规模和domain decomposition
一个Dyna计算所花费的时间主要分成两块,CPU计算时间及网络通信方面花费的时
间。对同 一个分好块的domain,CPU选定之后CPU计算时间基本上就确定了,但在网
络通信方面所花费的时间则根据网络设备和连接类型有大的关系。从比较典型 的汽车碰撞
过程中对mpi消息的tracer发现平均每个处理器每个周期发送28条消息,其中90%的消
息长度小于8K字节,67%小于1K字节[Ref 1]。一条消息的通讯时间依赖于两个因素,内
部连接的带宽和响应时间(bandwidth & latency)。另外消息传递过程中存在着竞争,当两
个或多个处理器试图通过同一网络通路传送数据时就会产生竞争。在基于IP的工作站网络
中,当两个机 器试图同时通过同一路径进行通讯,其中一条消息将延迟直到另一条传送完
毕,而这个延迟通常比实际直接传送两条消息所要的时间更多。
网络设备的bandwith & latency至关重要,带宽大,则传输同样数据所需时间少,
latency小,则等待时间会降低,同样有助减少通讯时间。在同样的CPU配置下,如果选
择bandwidth小,latency大的网络连接,则花在通讯上的时间所点的总时间比率增加,
大部分时间内可能CPU要等待从别的CPU传过来的信息 才能继续计算,这样导致单机的
CPU利用率不高,总的加速比没办法提高。就好比一部跑车开进了交通拥挤的低速道。因
此在选择网络设备时尽量选择 bandwidth大,latency小的硬件。这也是为什么目前大型
商用系统大多用myrinet,infiband替代GigE的原因。 除此之外,设备的参数设置与驱动
的tuning也会对加速比有所影响。目前操作系统和网卡驱动通常是根据平常的网络浏览和
交互进行参数设置的,对这样的应 用其效率比较高,但对LS-DYNA MPP这样的应用其
参数就不是最优的。前面已经提到在典型的LS-DYNA MPP计算过程中大量的消息为长度
小于8K字节的短消息,因此要对设备进行调谐以使得在短消息方面得到最佳性能。比如
在我组建过的做LS-DYNA MPP并行计算的linux cluster上,适当的进行网卡参数的设置
缩短了总的计算时间在7%左右。
MPI的选择在linux平台可以有很多种,HPMPI/Intel-MPI/MPICH/LAMMPI,前两
者通常是接合特定的硬件平台和执行块 进行优化,而后两都对自己组建的Cluster更容易
获得。从以前我自己组建的40CPUs 的Linux Cluster实际测试结果来看,在GigE作为
网络连接情况下同样参数设置和同样版本MPP Dyna执行块,LAMMPI的计算效率要稍
高于MPICH。DYNA MPP版本在不断的更新过程中,其不同版本的效率也不一样,从
topcrunch上也可以看出5434a版比3858执行效率就要高。
计算模型的规模和domain decomposition也是两个影响比较大的方面。规模小的模
型如果分的domain多,则很可能体现不出并行计算的优势。因为这样分在每个CPU上 的
CPU计算时间与网络通讯时间之间的比率会下降,CPU大部分时间可能在等待,加速比在
CPU超过一定数目时甚至会下降。domain decomposition方法直接影响分配到各个CPU
上的模型之间的公共节点的数目,如果两个domain之间共用的节点数多,则这两个
domain 分配到的CPU就计算过程中需要通讯的消息就多。在做Domain
decomposition时需要一些技桥巧和经验,尽量将各个domain之间的交界面减少。关于
Domain decomposition方面的详细参数设置可以参考lsdyna keyword user’s
manual中关于MPP的部分。
上面只是自己搭建LS-Dyna MPP并行平台方面积累的一点点经验,不能面面具道,
也可能会有些理解不对的地方,欢迎交流!
Reference:
1 . Message Passing and Advanced Computer Architectures.
Brian Wainscott and Jason Wang, LSTC.
2. A Correlation Study between MPP LS-DYNA Performance and Various
Interconnection Networks — a Quantitative Approach for Determining the
Communication and Computation Costs. Yih-Yih Lin, Hewlett-Packard Company
版权声明:本文标题:lsdyna mpp平台搭建经验 内容由热心网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:https://www.elefans.com/dongtai/1719112954a757029.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论