上尉
- 注册时间
- 2009-7-24
- 金币
- 1378 个
- 威望
- 0 个
- 荣誉
- 0 个
累计签到:6 天 连续签到:0 天 [LV.20]漫游旅程
|
高性能计算系统栈的推倒和重建(三)微处理机初期
. j2 G- M9 a/ H7 }8 a望洋兴叹7 l" ^' A0 j+ c9 ]) L7 ]
在专有机时代作并行计算的研究,你得会投“胎”。当时,全球科研的浪尖是在美国,能在Communications of ACM上发表论文的,都是美国大学的。用的HyperCube, Cray,Connection Machine 2 等大型机。而在英国,只有国产Transputer。 更可悲的是,我所在的埃德塞特大学(Exeter University), 我们当时只有四个transputer 节点。当时在英国,可以说是望着大西洋对岸的美国兴叹啊!我看美国人的论文的心情,就好比是一个穷人家的孩子偏偏喜欢上摄影,然后看着有钱人家的少爷拿着长焦、广角镜头,口水只能往里咽。
+ P/ X3 D% b& w0 t1993年,我到了美国阿冈(Argonne)国家实验室后,我就好像是小孩进了糖果店,因为那里有不少专有机(CM2, Paragon, Sequent等)。我问秘书预订了每个专有机的用户手册。每个手册都有电话簿那么厚,当秘书象我小时搬蜂窝煤一样把几英尺厚的手册搬进我的办公室后,她累得大抒一口气。现在看来,真是浪费了,这些手册我都没有用过。不是我没有用功,而是专有机被第一批微处理机颠覆了!
8 F4 S7 f/ x4 n( S- i2 F* b消息传送库pvm, P4和 MPI
5 z, P# A. A6 {5 J9 {# n( y; @在80年代时候,多种消息传输环境被开发出来。有些是为专有机开发的Ncube. 而另外不少是为Unix工作站开发的。比较有名的是Oak Ridge 实验室的PVM (Parallel Virtual Machines) 和阿冈(Argonne) P4 和PICL, Ohio 超级计算机中心的LAM。
- g, h5 w% C7 n- M: o8 m5 m+ V5 I当我看到PVM 的时候,我也就不望洋兴叹了。因为用工作站组装成一个超级计算机,不用花大钱去买专有机。而且写程序也是用常见的C或Fortran语言。不需要专有的语言。 一下子,高性能计算的世界在我眼前变平了。
) }" p2 K" k8 r! a# k) ^到了1992年末,听说又要搞个什么MPI。我和一帮英国同事都在笑,怎么又来一个消息传输库。后来才知道,我们笑得过快。原来,MPI是要吸百家之长、制定工业标准、省得大家重新发明轮子、浪费体力精力脑力人力。 Argonne和Oak Ridge 都是美国能源部的实验室。两个实验室,为了一个消息传输库争夺用户,结果使得能源部的应用开发成本提高两倍,这是实在说不过去。1994年这个标准终于出来了,不到两年的时间出来了这个标准,在HPC领域是相当快的。而且有许多学术界的人士参加的标准Forum, 一向是拖拖拉拉,没有目标导向,企图把海水烧开。为什么MPIForum 能够如此神速地推出此标准呢? 8 H( F' z* @. Q
这要归功于两个人,Bill Gropp 和 Rusty Lusk, 他们都是从阿冈国家实验室的科学家。不要笑,他们的抬头就是“科学家”。
( y6 n. }* a: |1 a$ B
" Y0 v4 B, K9 d) T2 B f1 c$ h. @" bBill Gropp Rusty Lusk S ^ W @( n
他们告诉我,最重要的原因,是MPI一开始就有一个参考实现:MPICH。 是他们两人主写的代码。所以,一旦有了一个可以参考的MPI库。一些应用就可以开始并行化。这样,许多没有任何应用场景的“好主意”,就很容易被扔到“Out of scope”栏目。帮助参加讨论者集中注意力。还有,他们采用的方法是一天早中晚连轴转的方式,如此高强度的讨论,只有那些铁杆、硬核的人才能挺得过去。所以,也把一些不懂行,不委身、但往往容易随机化讨论的人自然淘汰出局。% N* I9 g' F0 C! i! t
很多人把集群的概念归于Beauwolf. 其实,集群已经在九十年代初,就有了。许多人都以为,是beauwolf 集群后,工业界才开始使用。历史并非如此。听我给同学们表来。) U4 \. S& E2 x& z' b7 w9 ?
制造业最早的投入生产的微处理机集群
# j: f3 k7 J% X在美国East Hartford,驻扎着著名飞机发动机厂商 Pratt Whitney的设计中心。过去,为了测验叶片的强度,他们要将一个冰冻鸡扔向高速旋转的发动机上,然后分析断面。 毫无疑问,造价极高。后来,他们使用Cray来做模拟仿真。只是能够模拟单叶片。而且Cray成为稀有资源,每个工程师的作业,都要排上两天才能算上题。) c( F! x2 A: A& e( `
90年代上半叶,Pratt Whitney的CFD组,开始自主设计、开发一套消息传递系统,Prowess。它可以扩展到上千台太阳工作站。其中带头人名叫Craig Fischberg, 因此在制造业界成名。95年左右,GE 飞机发动机给了他双倍工资并为其妻子安排了很好的工作,把他挖了去。后来,他又用MPI 来为GE建立了同样系统。从此,他在GE 的地位如日中升。
" p& c ~: s+ m. K' i* A6 W一想起工作站资源觅食(Cycle Scavenging)人人都以为最早是由Seti@home. 其实,在九十年代初在Pratt Whitney 已经有了。
8 S9 T8 ^& V: e6 f% P9 N' r那么从Cray 到工作站集群到底带来什么大不了的效益,使得GE出血本要挖人才呢? 后来,Craig Fischberg 跟我讲,以前只能在叶片上模拟,后来能够把模拟整个发动机。以前的排队时间长至3天,结果晚上提交,第二天一早就可以看见结果。结果呢,高耗资的物理测试减少了,设计时间缩短了一半,而且飞机引擎的油耗效率大大提高。所以,GE能不受刺激吗?花了双倍工资挖到了Craig Fischberg是非常小的代价。8 _4 x+ E1 s a+ I- x1 U
成百上千的工作站的计算能力被完全释放出来。他们用的作业调度器是Platform Computing 的LSF。 所以,在九十年代,LSF的用户手册写着“Unleashing the Power” – 释放能力!就是从这儿来的。8 R, k6 v" m# e/ U' o5 {& U
商家简介
) G$ l" A5 w7 Y0 H机器厂商 IBM,SGI, HP 和SUN
# n7 m l P1 v6 R6 O硬件 精简指令芯片, ]! w$ J7 {9 F: N' f7 z$ y; @$ R9 o
处理器间网络联接 定制化的网络
: [ Q: E) ~1 y' O' F3 o应用软件编程界面 MPI-工业标准 PVM 和其他 消息传递软件包# C# Y9 Z6 K# ^$ m* Y
作业调度软件 LSF, PBS, Sun Grid Engine (SGE)* R# k( @' |1 D2 s9 l' V
( [ C& M- s2 A" u& T
为什么会有那么多的定制化的网络联接呢?我们下次再说。- ~- @# J$ N* ~% _
下次内容: 我和Rusty Lusk 的一个不开心遭遇引发我的奇想。
8 j! Q: k0 ~6 Z M W, D% WPosted: Thursday, September 03, 2009 11:13 AM by mingqxu | 1 Comments # _5 g P, t3 C+ \7 O9 u2 C. A
Filed under: 业界动态, 员工故事, BeautyFromAsh
3 e+ c$ R1 N) V: N" L高性能计算系统栈的推倒和重建(二) 专有机时期A 3 o4 H u/ B4 k0 [
选择并行计算, 被人泼了冷水* t, N0 O$ Q- I9 y# O+ o1 \ X
1987年春晚,费翔的故乡的云唱红。歌云:“归来吧,浪迹天涯的游子“。可我那时却踏上了留学之路。在研究人工智能高潮时候,我选择了并行计算。为什么要选并行计算呢? 当时我选主攻方向的标准非常单一,那就是越新越好。我出国的目的就是要学习最新的科学技术,因为当时我坚信只有科学才能救中国。当我把英国导师的研究计划提议书给国内导师过目时,他的第一的评语就是:”我看提议书中的许多参考资料都是当年或近年出的,是国际领先的方向“。
1 V2 P. m3 p) N( v/ D在英国1988年的“并行计算专家会议”上,我遇到一位工业界的人士, 互相介绍时候,我兴奋地告诉他我的博士主攻方向。 他的回答是我一生都不能忘记: “并行计算不会有前途的。将来人们将造越来越大的向量机。没有人愿意将自己的应用并行化,因为太难了”。& [, W/ W: L& `6 [3 _( U
现在看来,这个专家是大错特错了。 虽然如此,我还是非常赞赏他的坦率。他完全可以不必加什么评论,事不关己,可以高高挂起。他不愿意看见我往火坑里跳的精神可嘉。不过,专家的话也是要分析地去接受。而且,当你和专家有不同意见的时候,也不要迷信。 长江后浪推前浪,新一代要超过前一代。不迷信权威是科学向前发展必要倡导的精神。
: k5 l9 B7 e4 }8 c' ? w我没有相信他的话。
, c4 V0 T% H/ m) d+ F这段时间的高性能计算的生态环境如下: c) k9 C: w5 C& X9 {! j
机器厂商 Cray, Thinking Machines (CM-5), Sequent, Kendal Square Research (KSR), INMOS (Transputers)
- l% V1 M$ ]9 `& }! a4 h% @* I$ m硬件 定制化的芯片( J- r5 M* Y3 @
处理器间网络联接 定制化的网络
/ Y# n3 I2 Q, [软件 专有语言或FORTRAN的专有指令和工具. A, V8 F6 X" o! a: p
我们看见,“定制”“专有”这是造成价格天价的原因。 那时候,CRAY只有少数西方的国家实验室和大型制造业公司才能拥有。 只有少数先进国家才能拥有。杜甫一句诗词,似乎表达了我当时的意愿并有预言性:“安得广厦千万间,大庇 天下寒士俱欢颜”。 高性能计算关乎全世界的一项技术,它的益处不能被一个国家所禁锢和独占。这二十一年,我感觉有支看不见的手,把高性能计算机从国家实验室的围墙里,推出到制造业,电子业、生命科学和制药业,石油业,金融业。 从美国、推向西方先进的国家,又推向东方。 曙光和微软研制的两百万亿次计算机就是一个例子。" J$ [' p' ~& i' K9 H
小心处理器杀手
0 b3 ]% }, _, x2 j) d$ J" P" v( Q在一九九零时候,美国劳伦斯Livermore 实验室的Eugene Brooks 说了一句话:“Beware the killer Micros” (小心微处理器杀手)。 他这句话叫许多向量机的生产和设计厂商诚惶诚恐,为什么呢? 我在微软一个同事,Frank Chism, 曾经是Cray 的雇员。他告诉我,那时候每年CRAY的CEO和克莱斯勒的CIO的谈话是非常痛苦的。 克莱斯勒的CIO就问CRAY的CEO:为什么HP的工作站比你们CRAY要快,而我却要支付更贵的机器呢?“。 微处理机的日益强大的性价比使之取向量机而代之的成为必然。
7 q! N- J( Y2 [1 a# u% B1 B( M给我泼冷水的英国专家有句还是说对了,那就是并行化一个程序是很困难的,为什么别人会有人去做呢?不过他的话有个逻辑谬误,那就是:“没有人会去修改应用,因为太困难了“。 出力不讨好的事尚且有人做,更何况出力能讨到好的事情呢?这时候,美国制造业的一个企业,就成功地用工作站替代了向量机来解决计算流体力学的问题。我们下次再聊。
" @, p9 d# K3 P# b8 V, g对于专有机的Occam语言的三大遗憾
8 }/ L5 m2 r. r% l6 oOccam 语言是我接触并行计算的第一个语言。这个语言是以一个哲学家Occam命名。提起他,我们都知道有个Occam剃刀原则(Occam Razor)。 就是:“Keep it simple” 原则。这个语言之简练和直观不逊于其命名。它用Channel, SEQ, PAR 和ALT 等语言部件,可以构建各种并行进程及其通讯和同步场景. 下面程序实现了典型的生产者和消费者通讯的例子:8 p: ~2 I9 e' f- B& H+ k9 O
PROC producer (CHAN INT out!)
/ N' i8 c/ P: c. h! U$ X K INT x:; G; J9 l# d5 Y3 Z
SEQ% X, T) g S1 E5 g5 ]
x := 08 H/ @! U6 I# n$ _3 B
WHILE TRUE( Y4 }( d1 t7 P
SEQ6 \, h6 P7 {# F% G
out ! x, p; S8 @8 `! n2 N+ i- y, L
x := x + 1
) I$ i2 h Q" ^2 j% d+ v: H6 @, C) s$ }& O+ B2 Q- o& n
PROC consumer (CHAN INT in?)
8 ]: e* c' U V WHILE TRUE
e1 v7 ]+ d: U" V INT v:' [) J9 I4 J% _0 Y! C; p, [! Q+ b
SEQ
; l* G2 Q6 D: u' ]' U! G3 Q in ? v; F" G( x H2 ]- t& g: E
.. do something with `v'$ ?' R" {/ y) ^$ p; }
:
! |, ?5 c8 p4 H( p4 f! W/ yPROC network ()
9 L; ^% S$ K+ c' G6 Z8 z CHAN INT c:
! z) j- `. q* P4 N9 r g PAR2 H2 F6 _& \! g# p! |) Z7 h
producer (c!)
! I2 _* u( p5 X8 a Y5 W consumer (c?) Z Q: r2 J5 ^ P- k& {
:% f2 m( p2 l+ v$ a
我自然是被这个语言着迷。可惜好景不长,我立刻发现Occam 语言的三个局限:
1 K6 I- T$ C7 g- D遗憾一: 并行进程的静态、编译时决定的。不可能在运行时动态产生进程:
- e+ ?! p- N) x6 P# d1 r6 nPAR I = 1 to N; F3 }8 h7 n" v
Process (I)
0 f- s) ^6 Q6 H; t* _5 w3 \这里N必须是编译时就确定的常数。这样对编写通用目的程序库带来很大的麻烦。 就好比MPI 用户没有办法根据MPI Rank 和MPI_Size 来动态划分域,只能硬编码其处理单元数量,那么今天恐怕还没有Nastran 等ISV通用库。 和我一起做博士的某英国哥们,他曾说要解决这个问题。我一直很感兴趣,不停地问他技术细节,结果他说了半天,我还是不清楚。说句实话,到今天,我还是没有明白。 后来这个哥们找到了工作,放弃了博士。2 h) s1 }, z5 v8 a1 b
到了后来1996年,MPI-2制定的时候,我参加了关于动态创建进程的讨论。当时我已经加入了Platform Computing 作LSF, 可是这些MPI专家们对于如何映像进程到处理机的理解不够透彻。他们没有认识到,动态创建必须基于一个资源管理的调度系统。 而他们没有有效地将需求及时提供给作业调度厂商。结果,现在有许多的MPI2 动态创建进程的实现,但是没有哪个是和著名的作业调度器集成的。 原因就是,大部分作业调度器的资源分配是静态的。一旦资源分配后,就无法改变。到了Windows HPC Server起步在2004 年的时候,我设计作业概念就考虑到作业当能伸能缩的. 因此,Windows HPC Server 是为数不多能够支持MPI 2的作业调度系统。! V5 p8 J0 L a. ~, ?/ d. z0 A
遗憾二: Channel 是没有缓冲的。一个发消息的进程,如果对方不在受的时候,就会被阻。直到有接受消息的。开始还觉得没有什么,结果不知道多少看起来不会死锁的代码,结果给死锁了。比如,两个进程计算后相互交换结果如下,就会死锁。- |% F5 E# {# r4 ~" N
PROC left (CHAN INT toRight!, CHAN INT fromRight)" E( j9 v: m( N$ d" t. H
… compute
: w$ n' b# C! i6 V3 H* h0 i toRight ! localResult3 b2 N+ v" ~: F' f( @ S/ `
fromRight? neighborResult" S/ |, z% n( u/ i( z$ U
:5 @! G/ o* K* k9 Z5 O; a$ B# F5 w
PROC right (CHAN INT toLeft!, CHAN INT fromLeft)+ j) m* c( @& v. [
… compute
! Y6 n g2 L4 k- x# x toLeft ! localResult
# Q: _3 I; [' o0 C fromLeft? neighborResult0 y; D# p B1 S
:
/ J6 F6 [9 r+ eCHAN INT c, d:% S) s' @" n% v3 L9 X
PAR4 y4 G, p3 L! @
left (c!, d?)
- ~6 W7 R: N8 Q8 q: _; @/ u right (d!, c?)) U- Y x. a! D' p% V% E L; y# e2 |
原因就是,对于left 进程,toLeft! localResult 会被阻塞,因为right 进程还没有接收消息 。 right进程也同理被阻塞。现在同学们用MPI的时候,已经对于MPI 库中所提供的消息缓冲区习惯了. 当我发现此功能后,顿时心存感激。
! Q7 b1 D* Q0 y G8 A遗憾三:进程和物理处理机之间的映射是静态的
: f- t5 L* H. `7 d( p9 h这是一个致命的局限。如下所示,进程terminal, editor 和network 是在编译时被硬性映像到不同的处理机上。
8 u7 x5 u7 ~0 pPLACED PAR4 R/ n, d- r. s/ f4 Q6 w
PROCESSOR 1
2 _" f9 Z# F f* k9 c3 a! V9 ~3 q) N terminal (term.in, term.out)6 P4 G6 n8 ~; F2 F2 A& u* N
PROCESSOR 2
7 R2 @8 E2 }0 ~9 z# t0 N editor (term.in, term.out, files.in, files.out)
+ i1 X9 e: r0 V1 Y+ j$ Y PROCESSOR 3
$ g' F9 X0 c: N; H network (files.in, files.out)
0 K4 ]% L( X& Z( n' Q& D对于这个局限的极度不满,心中涌出强烈的愿望想要解决这个问题。人生很有意思,9年后,我终于开始解决这个问题,一作就是近十二年。这个问题就是如何应用动态映射处理机,就是作业调度器(Job Scheduler)的灵魂." `3 C2 N, g& o" G
(待续)
1 d8 }( G# b: d5 N6 V. DVisual Studio 2010 Beta1 中的 MPI Cluster Debugger
! ^* M# u& O9 h) @% f在Windows HPC中写过MPI程序的朋友们应该用过Visual Studio2005/2008中的MPI Cluster Debugger吧。网上也可以搜到不少关于这方面的使用教程(blog, white paper)。在集群中调试MPI程序感觉如何?MPI Cluster Debugger用起来方便吗?Visual Studio 2010 Beta1已经发布,我们HPC组对其中的MPI Cluster Debugger做了很大改进,尽可能地使它变得更加便捷。下面就跟随我一起看看吧!
6 N: _3 w( k' g* o# U9 {在同样的地方( 项目属性页面) ,我们找到了MPI Cluster Debugger。不同的是,原先寥寥无几的参数被现在的一群参数所取代。不过不必担心,我保证大家很快上手。其实,在大多数的情况下,只要填写其中的3个参数。对于其他参数,MPI Cluster Debugger会使用默认值。
4 w h$ x! [4 _( M. Y* n7 o # ^& n! f* q- s; x0 m2 g
既然要在Windows HPC Cluster中调试程序,那么总得指定集群的头节点以及运行MPI程序的计算节点吧。“Run Environment”就是我们的第一个必填参数。点击”Edit Hpc Node…”即可进入”Node Selector”对话框。在此框中,我们可以选择想要使用的集群和计算节点。既可以笼统地指定所需要运行的MPI进程的个数,也可以精确地指定在那几个节点上分别运行多少个MPI进程。在选择节点时,我们还能看到各节点CPU实时负载情况。若仅仅想在本机上调试,运行4个MPI进程,则填入”localhost/4”就可以了。
7 @/ w; P: j( S9 _ ^, r! E9 X A y1 l0 A1 W7 e; y+ r, w V5 o& A
0 M4 W( Z L6 k- @$ t另一个必填参数是“Working Directory”。这是MPI程序运行的目录,必须是一个本地路径。若不存在,MPI Cluster Debugger会帮你创建。“Application Command”是第三个必填参数,通常使用宏“$(TargetFileName)”即可。它指定了需要调试的那个MPI程序。
9 I# d9 B0 ~) r
4 Y1 B( {9 T! w. F2 c“Deployment Directory”参数是可选,默认值是”\\<HeadNode>\CcpSpoolDir\<UserName>”。安装好Windows HPC Cluster后,CcpSpoolDir就会被创建并共享。若不想使用该默认值的话,需要填入一个网络共享路径,并且用户有读写权限。
J5 U/ d7 E9 Q( Z* oVisual Studio 从2008 SP1开始就有“Debugger Type”参数,于是我们有了选择调试器的自由。通常选择”Native Only”。若你是用MPI .Net写程序的话,那就选择”Managed Only”。* O* E& Y4 A* E( m3 q. I
& ]9 J; |( {. M( Q) D1 @
其他参数我就不一一赘述了。每个参数都有解释,相信大家可以看明白。不明白的话,那就回贴问我吧。
5 i6 e- o: U& x0 |' Q填好以上参数,就可以使用MPI Cluster Debugger的基本功能了。按”F5”,你的程序及相应的pdb文件会被部署到刚才选的那些节点上,然后MPI进程就运行起来了。在”Output View”中,你可以看到MPI Cluster Debugger所做的工作。若有错误发生,在这里可以看到详尽的错误信息,不至于手足无措。在”Processes View”中,你将看到正在运行的MPI进程。% S. C1 p: ]" \% t' \
5 r, i/ v) J( X6 i7 v( D
& l/ k8 g1 d1 N" ]0 ~- o7 u以上是对MPI Cluster Debugger的简单介绍。在Visual Studio2010正式发布之前可能还会有一些改动。若大家有什么建议,欢迎回帖。谢谢! |
|