在Windows HPC中写过MPI程序的朋友们应该用过Visual Studio2005/2008中的MPI Cluster Debugger吧。网上也可以搜到不少关于这方面的使用教程(blog, white paper)。在集群中调试MPI程序感觉如何？MPI Cluster Debugger用起来方便吗？Visual Studio 2010 Beta1已经发布，我们HPC组对其中的MPI Cluster Debugger做了很大改进，尽可能地使它变得更加便捷。下面就跟随我一起看看吧!

在同样的地方( 项目属性页面) ，我们找到了MPI Cluster Debugger。不同的是，原先寥寥无几的参数被现在的一群参数所取代。不过不必担心，我保证大家很快上手。其实，在大多数的情况下，只要填写其中的3个参数。对于其他参数，MPI Cluster Debugger会使用默认值。

既然要在Windows HPC Cluster中调试程序，那么总得指定集群的头节点以及运行MPI程序的计算节点吧。“Run Environment”就是我们的第一个必填参数。点击”Edit Hpc Node…”即可进入”Node Selector”对话框。在此框中，我们可以选择想要使用的集群和计算节点。既可以笼统地指定所需要运行的MPI进程的个数，也可以精确地指定在那几个节点上分别运行多少个MPI进程。在选择节点时，我们还能看到各节点CPU实时负载情况。若仅仅想在本机上调试，运行4个MPI进程，则填入”localhost/4”就可以了。

另一个必填参数是“Working Directory”。这是MPI程序运行的目录，必须是一个本地路径。若不存在，MPI Cluster Debugger会帮你创建。“Application Command”是第三个必填参数，通常使用宏“$(TargetFileName)”即可。它指定了需要调试的那个MPI程序。

“Deployment Directory”参数是可选，默认值是”\\<HeadNode>\CcpSpoolDir\<UserName>”。安装好Windows HPC Cluster后，CcpSpoolDir就会被创建并共享。若不想使用该默认值的话，需要填入一个网络共享路径，并且用户有读写权限。

Visual Studio 从2008 SP1开始就有“Debugger Type”参数，于是我们有了选择调试器的自由。通常选择”Native Only”。若你是用MPI .Net写程序的话，那就选择”Managed Only”。

其他参数我就不一一赘述了。每个参数都有解释，相信大家可以看明白。不明白的话，那就回贴问我吧。

填好以上参数，就可以使用MPI Cluster Debugger的基本功能了。按”F5”，你的程序及相应的pdb文件会被部署到刚才选的那些节点上，然后MPI进程就运行起来了。在”Output View”中，你可以看到MPI Cluster Debugger所做的工作。若有错误发生，在这里可以看到详尽的错误信息，不至于手足无措。在”Processes View”中，你将看到正在运行的MPI进程。

以上是对MPI Cluster Debugger的简单介绍。在Visual Studio2010正式发布之前可能还会有一些改动。若大家有什么建议，欢迎回帖。谢谢！

见附件

10月21日：针对大赛发布的题目，更新了样例输入文件，以及示例中如何进行输出的部分。

金秋的北京，一年中难得的好天气，人们还沉浸在08年奥运会的喜悦中，而一项影响中国高性能计算发展的大事，也正在紧锣密鼓地进行 – 近两千台新研制开发的曙光5000A机器已从天津工厂运抵北京！这么多的机器太沉，一楼的地面无法承重，找不到合适的数据中心，造价两亿元的这两千台高性能计算服务器暂时落户在中科院计算所的地下车库里。

中国人的力量和速度再一次让世人惊叹：地下车库的改建，制冷水管的铺设，整个临时数据中心的建成一共只用了十天时间，夜以继日的努力只为了一个共同的目标 – 那就是11月中旬即将在美国奥斯汀举办的第21届超级计算机大会。世界权威的Top 500超级计算机排名将在这次大会上正式公布，跻身前列是每一个中国高性能计算工作者的梦想！

作为微软高性能计算中国开发团队的一员，我也有幸加入到这次影响中国高性能计算历史的努力中！曙光，是中国高性能计算的代表企业，与微软公司的结缘始于2007年底。一向依托于UNIX/LINUX高性能操作系统环境的曙光公司，对刚刚踏入高性能计算领域并于2006年发布第一版高性能计算产品Windows Compute Cluster Server 2003的微软公司，产生了浓厚的兴趣。这一过程是艰难的，压力与希望同在，挑战与机遇并存。

9月15日刚刚成功发布微软高性能计算的第二个版本Windows HPC Server 2008，我们来不及任何的休整，一行四人立刻踏上了北京的征程。清楚地记得第一次踏进中科院的地下车库，憋闷的环境，数千台机器共响的轰鸣声立刻让我觉得透不过气来。简易的工作台，没有任何的噪音隔离和防护措施，这就是我们接下来一个多月里需要战斗的地方。来不及多想，放下简单的行囊，立刻加入到这1920个节点部署Windows HPC Server 2008系统的工作中。这是第一次Windows HPC Server 2008产品在这么大规模的计算集群上部署和应用，我们的心情真是既兴奋又紧张。旁边来自曙光，AMD等各家高性能计算领域的同行们也都看着我们，想看一看初出茅庐的Windows HPC Server 2008到底表现如何。在基于Windows部署服务（Windows Deployment Service）的裸机部署模式的强大支持下，部署工作进行得异常顺利。部署完成后Windows HPC Server 2008简单易用的管理操作平台显示出了对近2000个计算节点的强大的管理能力，深得同行的赞誉，我们也终于舒了口气。

然而接下来的工作远没有期待中的这般顺利。一个刚刚搭建的数据中心，全新的硬件，全新的软件，对于一个至少需要连续运算7-8个小时才能取得较理想计算结果的基准测试来说，任何一个环节的细微差错，例如网络连接的松动，电源过热，15360条内存中任何一条内存的故障都会导致整个测试运行的失败。我们甚至发现，在如此大规模尚未经过时间考验的计算集群上，取得一个有效的测试结果都是相当的困难。当有节点发生故障时，我们需要和曙光的硬件工程师，来自Mellanox/Voltaire的网络工程师一起，登录到故障节点，查找可能的软件、硬件或者网络的问题，并对问题进行记录和总结。曙光也设立了简单的工作台，进行现场的故障硬件修复。如果用四个字来形容当时的工作状况，那真是“没日没夜”。从数据中心的搭建到最终Top 500的提交期限，一共只有不到一个半月的时间，每个人都不愿浪费一点点可以进行故障排查或者运行测试的时间，所以常常忘了外面是白天还是黑夜。经常拖着疲惫的身体走出计算所的大门，才意识到，早起的人们已经开始了晨跑，原来熬夜也是这么容易习惯的。更多的时候，我们也只是在车库角落里搭建的临时床，甚至机柜旁伴随着近2000台计算节点的轰鸣声席地而睡。

我们感激曙光公司在如此大规模的计算集群上率先采用刚刚发布的Windows HPC Server 2008产品的信任，但作为Windows HPC Server 2008在如此大规模的计算集群上的首次尝试，大家也曾犹豫和怀疑过。继9月29日取得116.3TFlops的运算结果之后，我们在将近10天的时间里一直无法取得任何的突破，眼看着提交结果的期限一天一天接近，怀疑的声音也开始出现。Windows HPC Server 2008真的是如此大规模计算集群的正确选择吗？在这样的质疑声中，顶住压力，永不放弃是我们的唯一选择。记得当时美国总部团队的老板们正在上海访问，和上海的团队讨论下一个版本的计划，但是在Top 500项目的巨大压力下，上海开发团队的主管严治庆于当晚就飞回了北京，还记得他那个时候诙谐地说：“不是天不助我，而是时机未到”。越是这样紧张的时候，越是要镇定，我们总结了前段时间屡屡失败的教训，为每次基准测试程序的运行制定了详细的准备步骤：包括各个节点的排查，网络状况的检查，小规模测试等等。虽然每次这些准备工作都需要花费2个小时左右的时间，但我们发现这对确保测试运行的成功率发挥了至关重要的作用。在10月9号的早晨，顶着巨大的压力，我们终于突破了140T的大关，我们终于证明了自己，证明了Windows HPC Server 2008对于大规模集群计算的能力，我想这是我们在Top 500道路上最艰难也是最重要的一个结果，连曙光的同行都表示没想到你们真的能跑出这个结果！

在整个Top 500的项目中，和我们一起并肩作战在中科院计算所地下车库里的还有一位法国朋友，他就是来自微软法国团队的Xavier Pillons。Xavier有着丰富的Top 500基准测试的经验，但是他表示像这次如此大规模的集群以及如此艰难的测试他还是第一次遇到。虽然作为他的第一次中国之行，Xavier在29天的时间里只得空休息了2天，但是他对此次的中国之行非常兴奋，记得在10月13号167.4TFlops之后的庆功宴上，Xavier自豪地说：“我们创造了中国高性能计算的历史，我很高兴成为其中的一员”！

在临近提交结果期限的两天，经过一次次地改进和测试，我们又取得了新的突破，180.6TFlops的结果，78%的效率对于Windows HPC Server的历史，对于中国高性能计算的历史都是划时代的，也为我们一个多月的辛勤工作，无数的不眠之夜交上了一份满意的答卷！在11月中旬召开的世界超级计算机大会上，我们非常荣幸地跻身全球超级计算机前十的行列，并成为在美国之外唯一一个进入前十的超级计算机集群！当怀抱奖状的时候，成绩的取得已经成为了过去，我们会怀抱更大的热情和理想做好Windows HPC Server的下一个版本，也祝愿中国高性能计算行业的发展越来越红火！

您想帮助我们一起改进Windows HPC Server 2008产品吗？请加入微软客户体验改善计划（Customer Experience Improvement Program）！只需要以下几步即可方便完成--

1) 打开Microsoft HPC Pack –> HPC Cluster Manager;

2) 在菜单中选择Help –> Customer Feedback Options;

3) 选择”Join the Customer Experience Improvement Program”，点击”OK”.

您的参与对于我们持续改进Windows HPC Server产品非常有价值！:)

大家好，我是HPC 中国研发团队的新程序经理（PM）实习生刘贤斐，听言“PM是连接用户和开发团队的重要角色”，因此，在加入微软HPC组之后，尽快熟悉微软HPC的产品成为我的重要任务之一，在在得到了包括老板George，育彤兄的大力支持以及天驰兄的大力PUSH之后，我成功地把Microsoft Windows HPC Server 2008(Beta1) 部署到了一台具备一个头节点4个计算节点的集群（Cluster）上。原来用HPC PACK部署集群是如此方便快捷（不是广告，看后面就知道了），其兴奋不言而喻，在此和大家分享一下我的经历。

       那么什么是集群（Cluster）呢？比较正式的解释是：集群（Cluster）是由两台或多台节点机（服务器）构成的一种松散耦合的计算节点集合，能够为用户提供各种服务。我们部署的集群外观是这样的：

HPC Server 2008的作用是在这上面部署操作系统以及集群管理工具等。先来说说HPC Server 2008的概念吧，它是由两个部分组成的：Windows Server 2008和Microsoft HPC Pack。

大家好！请接受微软HPC（高性能计算）上海开发团队全体成员的诚挚问候。

在微软，HPC组是服务器与开发工具事业部中积极推动全球分布式软件开发的一员先锋。不管是在美国华盛顿州的微软总部雷德蒙，在大洋彼岸的中国上海，还是在员工自主选择的其他工作地点，都有我们组员群策群力，协同开发的身影。

我们在中国组建一个开发团队，不仅是为了更方便地招贤纳才，更及时地聆听亚太客户的声音，更体现了我们对快速崛起的亚太地区市场，特别是HPC市场的重视和承诺。 在产品Windows HPC Server 2008中，上海开发团队主要负责的模块有：图形化管理界面, powershell脚本命令， 报表和一种新的面向服务架构的编程模型。我们是一个年轻而充满活力的团队，热切期望“牛人”的加盟。如果您愿意参与微软 HPC产品的开发，作为开发人员直接编写产品代码或测试代码，抑或是作为程序经理去决策做什么样的产品，联系我们吧！

在这个blog上，我们希望一两周发一篇文章，向大家提供HPC的业界新闻动态和Windows HPC Server 2008的开发进展，并希望与您交流一些您关注的HPC方面的问题。

Alex Sutton—司徒安

中国上海Windows HPC项目组经理

Hello from the HPC Shanghai team.

The HPC group at Microsoft is one of the pioneer teams doing distributed development in the Server and Tools Division at Microsoft. We have development teams in Redmond, Washington and Shanghai, China, with some other individuals scattered across the United States.

Having a team in China allows us to recruit and work with some of the top computer talent in the world. It also brings us closer to customers in the Asia Pacific region, showing our commitment to the HPC market and this rapidly growing region.

For Windows HPC Server 2008, the team is working on the GUI, scripting, reporting, and the new SOA programming model.

We’re a young and dynamic team, and are always looking for talented people to join us. So if you are in China or want to work in China on Windows HPC as a developer (writing product code or test code), or program manager (they figure out what to build) let us know.

We’ll be posting to this blog every few weeks or so to let you know more about what we are doing with HPC in China and Asia.

Alex Sutton—司徒安

Group Manager

Windows HPC

望洋兴叹

在专有机时代作并行计算的研究，你得会投“胎”。当时，全球科研的浪尖是在美国，能在Communications of ACM上发表论文的，都是美国大学的。用的HyperCube， Cray，Connection Machine 2 等大型机。而在英国，只有国产Transputer。 更可悲的是，我所在的埃德塞特大学（Exeter University）, 我们当时只有四个transputer 节点。当时在英国，可以说是望着大西洋对岸的美国兴叹啊！我看美国人的论文的心情，就好比是一个穷人家的孩子偏偏喜欢上摄影，然后看着有钱人家的少爷拿着长焦、广角镜头，口水只能往里咽。

1993年，我到了美国阿冈（Argonne）国家实验室后，我就好像是小孩进了糖果店，因为那里有不少专有机（CM2, Paragon, Sequent等）。我问秘书预订了每个专有机的用户手册。每个手册都有电话簿那么厚，当秘书象我小时搬蜂窝煤一样把几英尺厚的手册搬进我的办公室后，她累得大抒一口气。现在看来，真是浪费了，这些手册我都没有用过。不是我没有用功，而是专有机被第一批微处理机颠覆了！

消息传送库pvm, P4和 MPI

在80年代时候，多种消息传输环境被开发出来。有些是为专有机开发的Ncube. 而另外不少是为Unix工作站开发的。比较有名的是Oak Ridge 实验室的PVM (Parallel Virtual Machines) 和阿冈(Argonne) P4 和PICL, Ohio 超级计算机中心的LAM。

当我看到PVM 的时候，我也就不望洋兴叹了。因为用工作站组装成一个超级计算机，不用花大钱去买专有机。而且写程序也是用常见的Ｃ或Ｆｏｒｔｒａｎ语言。不需要专有的语言。 一下子，高性能计算的世界在我眼前变平了。

到了1992年末，听说又要搞个什么ＭＰＩ。我和一帮英国同事都在笑，怎么又来一个消息传输库。后来才知道，我们笑得过快。原来，ＭＰＩ是要吸百家之长、制定工业标准、省得大家重新发明轮子、浪费体力精力脑力人力。 Argonne和Oak Ridge 都是美国能源部的实验室。两个实验室，为了一个消息传输库争夺用户，结果使得能源部的应用开发成本提高两倍，这是实在说不过去。１９９４年这个标准终于出来了，不到两年的时间出来了这个标准，在ＨＰＣ领域是相当快的。而且有许多学术界的人士参加的标准Ｆｏｒｕｍ， 一向是拖拖拉拉，没有目标导向，企图把海水烧开。为什么ＭＰＩForum 能够如此神速地推出此标准呢？

这要归功于两个人，Bill Gropp 和 Rusty Lusk, 他们都是从阿冈国家实验室的科学家。不要笑，他们的抬头就是“科学家”。

Bill Gropp Rusty Lusk

他们告诉我，最重要的原因，是ＭＰＩ一开始就有一个参考实现：MPICH。 是他们两人主写的代码。所以，一旦有了一个可以参考的MPI库。一些应用就可以开始并行化。这样，许多没有任何应用场景的“好主意”，就很容易被扔到“Out of scope”栏目。帮助参加讨论者集中注意力。还有，他们采用的方法是一天早中晚连轴转的方式，如此高强度的讨论，只有那些铁杆、硬核的人才能挺得过去。所以，也把一些不懂行，不委身、但往往容易随机化讨论的人自然淘汰出局。

很多人把集群的概念归于Beauwolf. 其实，集群已经在九十年代初，就有了。许多人都以为，是beauwolf 集群后，工业界才开始使用。历史并非如此。听我给同学们表来。

制造业最早的投入生产的微处理机集群

在美国East Hartford，驻扎着著名飞机发动机厂商 Pratt Whitney的设计中心。过去，为了测验叶片的强度，他们要将一个冰冻鸡扔向高速旋转的发动机上，然后分析断面。 毫无疑问，造价极高。后来，他们使用Cray来做模拟仿真。只是能够模拟单叶片。而且Cray成为稀有资源，每个工程师的作业，都要排上两天才能算上题。

９０年代上半叶，Pratt Whitney的ＣＦＤ组，开始自主设计、开发一套消息传递系统，Prowess。它可以扩展到上千台太阳工作站。其中带头人名叫Craig Fischberg, 因此在制造业界成名。９５年左右，GE 飞机发动机给了他双倍工资并为其妻子安排了很好的工作，把他挖了去。后来，他又用MPI 来为ＧＥ建立了同样系统。从此，他在GE 的地位如日中升。

一想起工作站资源觅食（Cycle Scavenging）人人都以为最早是由Seti@home. 其实，在九十年代初在Pratt Whitney 已经有了。

那么从Cray 到工作站集群到底带来什么大不了的效益，使得ＧＥ出血本要挖人才呢？ 后来，Craig Fischberg 跟我讲，以前只能在叶片上模拟，后来能够把模拟整个发动机。以前的排队时间长至3天，结果晚上提交，第二天一早就可以看见结果。结果呢，高耗资的物理测试减少了，设计时间缩短了一半，而且飞机引擎的油耗效率大大提高。所以，ＧＥ能不受刺激吗？花了双倍工资挖到了Craig Fischberg是非常小的代价。

成百上千的工作站的计算能力被完全释放出来。他们用的作业调度器是Platform Computing 的LSF。 所以，在九十年代，LSF的用户手册写着“Unleashing the Power” – 释放能力！就是从这儿来的。

商家简介

为什么会有那么多的定制化的网络联接呢？我们下次再说。

下次内容： 我和Rusty Lusk 的一个不开心遭遇引发我的奇想。

有几位读者在之前的高性能计算文章上留言，表示这个话题离主流开发人员太远。其实微软的DNA就是将复杂的东西变得简单，把给少数人群使用的能力传播给大多数人。因此节选了《微软高性能计算服务器》”第三章 使用作业调度系统“中两个实际操作章节与读者共享。

作业调度系统提供了许多作业提交和管理的方式。通过友好的界面，用户可以方便地提交和管理作业。通过应用编程接口，第三方软件商可以实现与作业调度器无缝集成。通过脚本和PowerShell功能，管理员可以编写各种方便最终用户运行应用的脚本文件。

本章要点

• 理解作业管理器的概念和使用原则
• 使用用户界面、C#应用界面、命令行和强大脚本提交作业
• 使用用户界面监控应用运行情况

3.1 作业调度系统概念

集群是Windows HPC Server 2008 R2的顶级单位。一个集群包含下列元素。

• 节点：具有一个或多个处理器的单一物理或逻辑计算机。节点可以是头节点、计算节点或 WCF Broker节点。
• 队列：提供排队和作业调度功能的元素。每个 Windows HPC Server 2008 R2集群都只包含一个队列，且该队列包含挂起的作业。已完成的作业将从队列中定期清除。
• 作业：由用户启动的一组任务。作业用于保留资源以供随后的一个或多个任务使用。
• 任务：是指在给定的计算节点上执行的程序。其可以是串行程序（单一进程）或并行程序（使用多线程、消息传递接口 [MPI] 或 OpenMP）。

作业调度程序用于对作业及其任务排队。它为这些作业分配资源，启动集群计算节点上的任务，监视作业、任务和计算节点的状态。

3.2 安装应用

博主注：本书附带光盘为Windows HPC Server 2008 R2试用软件安装盘，可为读者提供180天的免费试用。此处安装顺序略去。

3.3 提交作业

第2章介绍了作业提交有多种方式。本章详细介绍3种方式：使用作业管理器；使用命令行和PowerShell；使用C#程序。

3.3.1 使用作业管理器

（1）开始-〉所有程序→Microsoft HPC Server 2008 R2→HPC Job Manager。

（2）在“操作”方框下，单击“新建参数扫描作业”，弹出“新建参数扫描作业”对话框，如图3-2所示。

图 3‑2 创建参数扫描任务

（3）在“任务名”文本框中，键入作业的名称“AsianOptions Valuation by Interest Rate”。

在“步骤1”中，键入起始值为“0”，最终值为“9”。

在“步骤3”中，键入命令行“AsianOptions.exe 1.0*”。

在“工作目录”文本框内，键入“\\<headnode>\Applications”(将<headnode>替换成您的头节点名)。

（4）预览参数清除任务。如果任务不是如图3-3所示，请进行更改，并再次预览。

图 3‑3 设置命令行、工作目录

注意：

设置任务访问必需数据的方式是在作业提交时获得最佳任务性能的一项重要因素。该设置应随数据集的大小和稳定性而异。如果数据集不会经常更改且相对较大，则应将其设置为任务的本地数据。如果数据集较小，可通过文件共享方式访问。如果数据集很大且会经常更改，则需将数据传送到节点。Windows HPC Server 2008 R2 支持并行和高性能的文件系统来提高对非常大的数据集的访问性能。通过指定工作目录，小型和中等数据集的用户将获得最佳的即用即取的体验。当任务开始时，计算节点将看到此工作目录中的所有文件并可正确处理该任务。

（5）单击“提交”按钮。此时，用户回到了作业管理器。 在所有作业列表内，您会看到作业正在运行。等几秒钟后，作业结束，如图3-4所示。

图 3‑4 监控参数扫描作业

（6）在任务标签下，双击如图3-4所示的“任务1.1-1.10”，弹出“查看作业”对话框，如图3-5所示。上面是所有的10个任务的列表。当选择一个任务的时候，可以看见计算结果在“输出”的文本框内，比如，如果选第四个任务，会看到如下的输出：“Option Price / interest rate (1.03) = 9.15572854540851”(注意：结果不一定完全一致，因为这里采用的是蒙特卡罗算法，结果有随机性)，如图3-5所示。

图 3‑5 查看参数扫描任务细节

3.3.2 使用作业调度器命令行程序

（1）启动命令提示符。

（2）键入“job submit /parametric:0-9 /workdir:\\shpc-0110\Applications AsianOptions.exe 1.0*”。此命令将输出作业的ID，如图3-6所示。

图 3‑6 使用命令行提交参数扫描作业

（3）监控作业状态：在命令提示符窗口里键入“job view 33”，结果如图3-7所示。

图 3‑7 使用命令行监控作业

（4）显示某任务输出结果：在命令提示符窗口里键入“task view 33.1.<参数扫描序列号>”。例如，看第四个任务输出，键入“task view 33.1.4”，按回车键，结果如图3-8所示。

图 3‑8 使用命令行显示输出结果

3.3.3 使用Powershell

（1）启动HPC PowerShell：选择“开始-〉所有程序→Microsoft HPC Pack 2008 R2→HPC PowerShell”。

（2）在HPC PowerShell提示符下，键入“New-HpcJob”，按回车键，结果如图3-9所示。

图 3‑9 使用PowerShell创建作业

（3）然后，键入“Add-HpcTask -JobId 35 -Parametric -Start 0 -End 9 -WorkDir \\shpc-0110\Applications -CommandLine "AsianOptions.exe 1.0*”，按回车键，结果如图3-10所示。

图 3‑10 使用PowerShell添加任务

（4）键入“Submit-HpcJob -Id 35”，按回车键，结果如图3-11所示。

图 3‑11 使用PowerShell提交作业

（5）监控作业状态：键入“Get-HpcJob –Id 35”，按回车键，结果如图3-12所示。

图 3‑12 使用PowerShell监控作业

（6）显示任务结果输出：为显示第四个任务的结果，键入“Get-HpcTask -JobId 35 -TaskId 1 -SubTaskId 4 |fl”，按回车键，结果如图3-13所示。

图 3‑13 使用PowerShell显示作业输出结果

使用命令行和Powershell小结

作业调度器命令行和PowerShell使用小结如表3-1所示

表 3‑1 作业调度器命令行和Powershell使用小结

有客户问，如何从HPC的报表数据库中查询某段时间某个计算节点上在运行什么作业，以下是我的答卷。

function Global:Query-JobHistory([parameter(Mandatory=$true)][string] $NodeName, [parameter(Mandatory=$true)][DateTime] $StartTime, [parameter(Mandatory=$true)][DateTime] $EndTime)

{

	$connection = New-Object System.Data.SqlClient.SqlConnection("Data Source=.\computecluster;Initial Catalog=HpcReporting;Integrated Security=True;")

	$connection.Open()

	$cmd = $connection.CreateCommand()

	$cmd.CommandText = "SELECT DISTINCT JobID FROM AllocationHistory INNER JOIN Node ON AllocationHistory.NodeId = Node.NodeId WHERE NodeName=@NodeName AND StartTime <= @EndTime AND EndTime >= @StartTime  ORDER BY JobId"

	$cmd.Parameters.AddWithValue("@NodeName", $NodeName.ToUpperInvariant()) | out-null;

	$cmd.Parameters.AddWithValue("@StartTime", $StartTime) | out-null;

	$cmd.Parameters.AddWithValue("@EndTime", $EndTime) | out-null;

	$reader = $cmd.ExecuteReader();

	while ($reader.Read()) { $reader.GetInt32(0); }

	$reader.Close()

	$connection.Close()

}

使用步骤为:

1)保存以上脚本到本地磁盘，比如存为c:\scripts\Query-JobHistory.ps1

2)以管理员身份运行PowerShell，执行以下命令

	Set-ExecutionPolicy RemoteSigned

	c:\scripts\Query-JobHistory.ps1

	Query-JobHistory -NodeName:PAERSCBBLA0863 -StartTime:"02/17/2011 16:45:00" -EndTime:"02/17/2011 16:46:00"

 

原文发表地址：英文：Scale-out computing on DevLabs 中文： 在DevLabs上的扩展计算
原文发表时间：26 Jan 2011 10:30 AM

今天我们在DevLabs上建立新的技术计算（Technical Computing-TC）项目。一些技术会被作为技术计算计划的一部分开发出来， 这些项目为你提供学习这些技术的机会，能更早地获取代码，从而提供一些对TC相关的创新项目的反馈。

去年五月， 我写过一篇关于Micorsoft的技术计算计划的博文，这个倡议旨在能够赋予世界上最重要的问题解决者能最优化地利用计算资源的权利。 这些领域的专家常常要不就自己开发代码，要不就依赖别的开发人员来开发软件以实现他们的工作。TC计划给予那些开发人员和领域专家突破性的开发工具和架构来将工作做到最好。

TC计划自创立之初已经踏出非常重要的第一步。Visual Studio 2010支持开发、调试和优化多核应用程序，已经在各种不同的行业和领域获得广泛采用。11月，我们发布高性能计算服务器(HPC Server)2008 R2的Service Pack1。它整合了Windows 云计算周期，能很简单地将并行应用程序从群集扩展到云。这只是开始。加入TC计划的团队正在非常努力地开发新的出色的解决方案，以将所有现代和未来计算所拥有的全部都带去给开发人员，领域专家和IT专业人士等等。。

今天的新TC项目正在准备采取下一步行动。

TPL 数据流- 实现并行和并发的.NET应用程序

.NET 4中引入了任务并行库(TPL)、并行循环、并发数据结构、并行LINQ(PLINQ) 等等，所有这些都统称为.NET Framework的并行扩展。 TPL数据流是其中的新成员， 位于所有任务、同步集合与更多其他扩展之上，从而利用数据流的理念而构建的强大而有效的基于.NET的并发系统的开发。该技术依赖于基于进程中消息传送和异步流水线的技术，灵感大部分来自于Visual C++ 2010异步代理库和DevLab的Axum语言。TPL数据流为数据缓存、数据处理提供解决方案，构建高吞吐、低延迟的数据处理系统和基于代理/参与者的系统。 TPL数据流还被设计用来和C#与Visual Basic中的新异步语言功能集成——我在之前的博客中写过的。

下面，你们将看到一个在C#中使用数据流块来安全异步有效地处理进入请求的“agent”示例。

Dryad – 支持数据密集型应用程序

作为微软研究院的先锋，Dryad, DSC和DryadLINQ是一系列在Windows HPC Server 2008 RC Service Pack 1上支持数据密集型计算的应用程序。 这些技术实现在很多不同类型的应用程序中——包括数据挖掘应用程序、图像和流处理和各种不同的极大的科学计算——高效率地处理大量数据。Dryad和DSC在群集上运行以支持数据密集型计算并管理分布在群集中的数据。而DryadLINQ则允许开发人员使用熟悉的LINQ编程模型创建数据密集型和计算密集型.NET应用程序。

下面你能看到使用Dryad来加载文本日志数据的代码。 那个数据被合并到集群中处理， 然后结果会显示回客户端：

ublic static IEnumerable GeoIp(string logStream, string geoStream)
{
DistributedData logLinesTable = DistributedData.OpenAsText(logStream);
DistributedData geoIpTable = DistributedData.OpenAsText(geoStream);

// Join the two tables on the common key (IP Address)
IEnumerable joined = logLinesTable.Join(geoIpTable,
l1 => l1.Split(‘ ‘).First(),
l2 => l2.Split(‘ ‘).First(),
(l1, l2) => l2).AsEnumerable();

return joined;
}

public static void Main()
{
// Load log and geo data into DSC
Console.WriteLine(“Loading data”);
File.ReadLines(“log.txt”).AsDistributed().ExecuteAsText(“hpcdsc://localhost/Samples/log”);
File.ReadLines(“geo.txt”).AsDistributed().ExecuteAsText(“hpcdsc://localhost/Samples/geo”);

// Run the query
Console.WriteLine(“Running query”);
IEnumerable results =
GeoIp(“hpcdsc://localhost/Samples/log”, “hpcdsc://localhost/Samples/geo”);

// Print out the results
Console.WriteLine(“Displaying results”);
foreach (var entry in results) Console.WriteLine(entry);
}

Sho – 赋予你灵活开发原型进行数据分析的权利

也是始于微软研究院， Sho对从事技术计算工作的人提供了一个作数据分析和科学计算的交互式环境。 它让你通过.NET库文件无缝连接到写在IronPython中的脚本，实现快速敏捷的原型开发。 环境包括针对线性代数和数据可视化的强大而高效的库文件，二者都可以通过任何.NET 语言使用， 是一个可以实现快速开发的功能齐全的交互外壳程序。Sho自带处理大规模并行计算的程序包（通过Windows HPC Server和Windows Azure）、统计与优化、以及一些能让你易于创建和共享自己的程序包的扩展包机制。

如你在下图所见，Sho提供一个允许你即时以文本和图形方式呈现的编写和查看代码的方式。

试试看吧

我们下一步是往DevLabs添加一个pre-beta状态里的额外的技术计算项目，从而能更早地得到你们的反馈和意见，帮忙指导这些技术往正确的方向发展。 期待能收到你们的反馈。

Namaste!

摘要

为了支持绿色IT行动，随着Windows HPC Server 2008 R2 (SP1)的发布，我们在Windows HPC Server 2008 R2 (SP1) Monitoring Management Pack 添加了两个可配置的规则：“基于时间的能耗管理规则”和“基于利用率的能耗管理规则”

·          基于时间的能耗管理规则

此规则可以在一周的某几天和一天的某时段内，将一部分计算节点休眠以降低能耗。

 ·          基于利用率的能耗管理规则

此规则通过监控一段时间内集群的负载状况和作业队列长度，以决定是否将部分计算节点休眠以降低能耗。

此规则定义了三个级别的集群可用率，每一次休眠的条件触发时，集群的可用率将调整到下一个级别；另一方面，当唤醒的条件触发时，集群的可用率将调整到上一个级别。

 配置规则

在默认情况下，以上两个规则都被禁用。在SCOM服务器导入Windows HPC Server 2008 R2 Monitoring Management Pack后，管理员可以方便地启用、配置规则。

打开SCOM的界面，进入“Authoring”界面，选择“规则”，查询关键字“Power Management”，你就可以发现这两个规则，如下图所示：

下面是一些重要配置的默认值，管理员也可以对默认值进行修改

节能性能评估

为了评估节能性能以及对作业吞吐量的影响，我们进行了以下实验

(1)   安装一个HPC集群，该集群包含1个头节点，1个代理节点以及4个计算节点

(2)   模拟一个典型的工作日内的作业提交情况：

同时，作业运行时间分布如下：

(3)   在以下三种情况比较节能性能以及对作业吞吐量的影响

a.     禁用能耗管理规则

b.     仅启用时间能耗管理规则

c.     仅启用利用率能耗管理规则

 下面是实验结果：

·          节能效率

我们使用休眠的节点数量乘以休眠的时间来衡量节省的能耗。在使用时间规则时，有2个节点从22：00至7：00处于休眠状态；使用利用率规则，有2个节点从21：00至9：00处于休眠状态。两种规则都起到了很好的节能效果，相比之下，利用率规则更胜一筹。

·          可用核利用率

 利用率规则取得了最高的可用核利用率（49.1%），其次是时间规则（47.1%）。在没用启用规则的情况下，利用率为42.7%。

·          对作业吞吐量的影响

作业吞吐量代表了每小时完成的作业的平均数量；启用两个规则，对作业吞吐量没有影响。

·          对作业周转时间的影响

作业周转时间代表了一个作业等待时间与作业运行时间的比率。在启用利用率规则之后，作业周转时间有微幅提高（从0.436增长到0.437）；时间规则对作业周转时间没有影响。

结论

基于以上的模拟评估，在不影响作业吞吐量和作业周转时间的前提下，能耗管理规则能提高集群的能耗效率，真正实现集群的绿色ITJ

HPC Pack 2008 R2的第二个Service Pack正式发布了! 这次更新包括很多好东西：

• 加强与Azure的集成，比如把添加Azure VM节点加入您的 集群，创建Azure节点配置脚本和支持远程桌面连接。
• 把MPI程序提交到Azure中运行。
• REST接口的作业调度支持和基于IIS的作业网站。
• 一种新的使用“资源池”来保证不同用户组使用计算资源的作业调度策略。
• SOA改进，比如支持更快速的“进程内代理”和一种新的“公共数据”中转功能
• 还有其他通常的service pack稳定性改进。

如需更多信息，请参阅TechNet文档。SP2安装文件适用于Express版和企业版，以及单独的“客户端工具”和“MS-MPI”包。您可以从微软下载中心下载。值得注意的是这个service pack本身不能被卸载，除非完全卸载HPC Pack整个产品。所以如需“回滚”，您需要在安装前做完全备份（包括数据库）。

如果您还没有HPC Pack 2008 R2集群，可以下载一个免费的Windows HPC Server 2008 R2试用版。安装前，您还可以尝试一下新的安装准备向导，以分析您的环境，检测常见问题，并提供最佳实践建议来帮助您轻松完成HPC集群安装。

如有任何问题和建议，我们非常乐意听取，请移步Windows HPC 论坛。

(转载自 http://www.hpc-in-finance.com)

在如今瞬息万变的金融市场中，拥有速度就意味着更高的生产力和更多的市场份额 —— 时间就是金钱的铁律被无限尊重。金融分析师都迫切地需要一个能模拟复杂现实环境，并进行精确处理的金融计算程序，以便对每个投资产品及时地评估投资收益，衡量投资风险，以期获得更好的投资回报。也正因此，高性能计算（High-Performance Computing，简称HPC）已经越来越多地应用到全球资本市场，以期在最短时间内实现对市场的动态响应与转换。

为培养具备国际视野的金融人才，促进中国金融计算学科与金融产业共同快速发展，普及高性能计算在金融服务行业的应用，微软亚太研发集团、摩根士丹利管理服务(上海)有限公司和上海超级计算中心联合举办“微软–摩根士丹利杯”2011金融超级计算挑战赛。

大赛宗旨：旨在激发和培养中国学生的跨界应用创新技能和团队协作精神，发掘优秀的复合型人才。

主办单位：微软亚太研发集团、摩根士丹利管理服务(上海)有限公司、上海超级计算中心（以下简称“竞赛组织方”）

协办单位：上海万得信息技术股份有限公司

参赛对象：中国大陆地区高等院校的在校本科生与研究生

参赛者必须年满18周岁。如参赛者不满18周岁，则其参加本竞赛活动中的民事行为（包括但不仅限于接受本条款和条件）均需由其监护人代理作出。

参赛人员包括中国大陆地区的公立或民办学院/大学（以下简称“参赛机构”）中在册的所有本科生和研究生（包括外国学生，以下简称“参赛者”），都有资格参加此次竞赛。但竞赛组织方及其关联机构、子公司、及协办公司雇员及其家庭成员不得参赛（家庭成员包括父母、子女、兄弟姐妹、配偶和生活伴侣）。

参赛者选拔及奖励：

1. 此次比赛的获奖人员名单将在 2011 年 11月5日公布。

2. 竞赛组织方将共同评选出三组优胜团队，分别授予“最佳软件设计奖”（Best Software Design Prize）、“最佳金融模型奖”（Best Financial Model Prize）和 “最佳并行计算奖”（Best Parallel Computing Prize）。竞赛组织方就有关获奖学生和获奖指导教师所做的决定为本次大赛具有约束力的最终决定。

3. 优胜团队将获得最高价值人民币伍万元的实物奖励，其中学生的实物奖励价值不超过人民币肆万元整，指导教师的实物奖励价值不超过人民币壹万元整。优胜团队还将受邀参加在上海举办的挑战赛颁奖典礼、与组织方高管及金融行业专家面对面交流，并参观组织方的办公环境。所有优胜团队的学生可优先申请进入组织方的实习生招聘流程。

4. 奖励条件：

·竞赛组织方保留取消违反任何竞赛条款和条件的获奖者奖励的权利。

·由任何有关政府或税收机构对学生实物奖励和指导教师实物奖励征收的税款完全由获奖学生和获奖指导教师承担，竞赛组织方将承担代扣代缴义务，并直接从涉及实物奖励的金额中将个人所得税款扣除缴纳主管税务局。

截至目前，不少同学已经报名参加了“微软–摩根士丹利杯”2011金融超级计算挑战赛，同时在MSDN“微软–摩根士丹利杯”2011金融超级计算挑战赛论坛上提了一些很好的问题，主要集中在主办方发布比赛题目以前，如何准备上。每个人的学习方法不尽一致，这里我来给一些友情建议，供大家参考。

1)准备开发测试环境
1.1)集群环境：需要另外准备几台x64计算机,安装Windows HPC Server 2008 R2 Suite = Windows Server 2008 R2 HPC Edition操作系统（是一种特殊的Windows Server 2008 R2版本）+ HPC Pack 2008 R2，分别用作域控制节点、头节点、WCF代理节点、计算节点。最少最少需要一台计算机来兼任所有上述角色。安装部署和使用可参见Windows HPC快速起步（友情提示：MSDN已有其中文版本）。
1.2)开发用机：PC即可，但需加入1.1）中建立的域，安装HPC Pack 2008 R2 Client Utilities Redistributable Package with Service Pack 2，Windows HPC SDK和代码示例，VS2010和 VS2010插件。

2)学习相关技术
2.1)如需了解并行计算基础知识，请阅读参考资料上海超级计算中心部分，MPI部分仅供了解。
2.2)如需了解本次大赛编程模型知识，请阅读参考资料微软部分。如时间允许，最好是通读《微软高性能计算服务器》；如时间仓促，至少阅读要Windows HPC SOA技术白皮书和SDK的一些示例，比如亚洲期权定价（AsianOptions）。其中AsianOptions是很好的例子，如何使用SOA模型进行并行金融计算。您可以通过如下步骤学习AsianOptions示例。

• 下载《微软高性能计算服务器》书中示例代码
• 解压后打开HPCBookSamples\Chapter 4\Default.htm
• 点击”Introduction To Microsoft HPC Pack 2008 R2 SDK“部分的“Document”链接，学习Hello World的HPC SOA程序。
• 点击”Introduction to Parallel Computing on Microsoft HPC Pack 2008 R2“部分的“Document”链接，学习AsianOptions程序。其中Task 2 – Creating the Client Application仅供参考，比赛中不会用Excel作客户端程序，选手们需要自己编写一段C#的程序作客户端程序。

2.3)如需了解金融模型有关知识，请阅读参考资料摩根士丹利部分

我们知道所有程序都会和各种资源打交道，硬件资源类型如硬盘，系统资源如句柄，因此如何做好资源相关的测试很重要。大家熟知的是测试资源的泄漏，但这里我想更多的从资源分配失败及恢复角度去谈资源分配测试。

    对于资源通常有如下操作：

1．分配资源

   我们熟知的一个典型例子就是 C语言中'malloc()' 系列函数。

2．释放资源

   同样的一个例子就是C语言中'free()'系列函数。

3．资源计数

   比较常见的例子就是性能计数器，比如文件句柄计数器，它能够提供“有多少文件句柄被打开”的信息

    我们编写软件的时候，我们一般都会经常使用这些资源管理类函数来帮助我们，从而得以申请和释放多种类型的资源。当然我们也会编写一些自己的代码来申请和释放资源。一般情况下，这些代码会处于我们的软件架构的相对底层上。我们可能有一个系统，在这个系统里，我们分配资源，使用资源，还可能管理并监控资源，最后当处理完后释放掉这些资源。同时还存在着当代码运行时替我们分配资源的情况。

    由于各种原因，资源的申请和分配并不总是能够成功的。其中一个原因可能是某种特殊的资源被消耗殆尽了。比如在磁盘空间不够时，我们申请使用更多磁盘资源的话就会失败；还比如内存总是是有限的；句柄空间总是那么多。总之软件有可能因为各种原因而出错，但一个主要的原因就是资源的消耗。

    对于服务型软件而言，提供长期稳定的服务是重要的设计目标之一。从而，相对于客户端程序，它需要运行得更加可靠、健壮。为了确保软件的可靠性和健壮性，我们必须确保它在资源可用率发生异常变动的情况下，它还是可以正常运行。如果某一个程序消耗了所有的内存，那么我们可以假定它肯定会出错了；但如果由于系统内存的不足导致内存分配的偶尔失败，那么我们的软件应不应该完全崩溃？还是应该仅仅让当前操作出错并让软件其他部分能够继续正常运行？同样的问题也适用于其他类型的动态分配并被共享的资源，比如磁盘空间，内存，文件，网络连接等。

    致错测试是一个重要的测试场景，可以帮助我们了解当资源使用达到极限的时候会发生什么。简单地说， 这种测试可以用以下伪代码描述：

Pallocatedthing[<use more than enough space here>]

counter n

While(Pallocatedthing[n++]=allocate(<whatever size you like>))

While(n)

free(Pallocatedthing[n--])

    这种测试很简单，就是申请分配资源直到失败，然后释放掉所有分配的资源。这只是一种最简单的测试，如果你确保它可以工作了，那么还有几件事情等着你去做。

    首先，将它放到一个循环里面，然后执行很多次。它是否依然可以正常工作？

    其次，在它运行的时候观察整个系统，看被测试进程是否有内存，句柄或者其他资源的泄漏。这种场景下的一个典型的BUG就是资源分配函数发生错误时没有被正确处理。即使它不会立即导致崩溃，但仍可能会导致内存泄漏或者错误。这种事情我以前也遇到过。

    如果要更深入此类测试场景，则需要理解资源的依赖关系，以及在软件依次消耗掉所有的这些资源情况下其是否正确处理了所有的资源错误。这方面的一个例子就是处理消息的软件。它将在等待处理的消息在磁盘上保存为一个队列。那么磁盘如果满了的话会发生什么？这种场景可能会比较难设置，它看起来类似于：

1. 限制硬盘空间

2. 将消息注入到队列中

3. 停止从队列中取消息

4. 磁盘满了，会发生什么？相应的工作行为是正确的吗？

5. 重新开始从队列中取消息。是否一切工作正常？

    接下来的几个步骤类似于我们上面已经做的，那就是在更多的情况下去重复测试它，并观察结果：

    尝试取出所有的消息，直到队列为空。

    建立一个稳定的消息输入流，但时而暂停并再恢复取出消息，反复执行磁盘空间测试用例，看是否在这样的情况下仍然工作正常？ 如果出错的话，是否该出错被正确处理？是否有副作用，比如内存泄漏，句柄泄漏或者数据出错？是否队列的生产者和消费者都正确处理了错误用例？

    在你的软件中还会有很多关于这个主题的情况等待你去挖掘，我不准备将所有可能的情况都列在这里。我想你能够自己考虑这些事情。

John Daly

高性能计算美国团队测试经理

翻译：周毅， 高性能计算(HPC)中国团队测试开发工程师

          服务器与开发工具事业部（中国）上个月举行了热闹的新年晚会。除了吃好喝好，欣赏到了同事们精彩搞笑的节目(George使出了耍酷的老本行，为我们组赚够了眼球)，我们还荣获了部门的年度最佳客户关怀奖（Best CARE of the Year 2008 )。 CARE 取自Customers Are Really Excited，该奖旨在肯定我们团队在过去一年中与客户和合作伙伴的积极合作和突出贡献。    

        回顾我们与客户的互动大史记，自2005年我们成功地与上海交通大学和上海超级计算中心建立合作伙伴关系，开展微软高性能计算学院项目，之后制作一系列的网络广播(webcast)，创建了这个中文博客，多次在TechEd等技术会议上发表演讲，积极推广高性能计算的普及。

         2008年11月，一个运行Windows HPC Server 2008系统的超级计算机集群跻身世界最强500台计算机的第十名. 我们团队的George Yan，丛兰兰，朱仁琪，史秋芳与雷德蒙及微软中国技术中心的同事，与曙光公司一道，排除万难，才取得了最后的好成绩。时至今日，这个集群仍是世界上最大的Windows系统的集群，也是在美国之外跑得最快的一台超级计算机。       

        最后，送上一张我们团队的最新全家福，想加入我们这个其乐融融“挤挤一堂”的大家庭吗？点击网页上方的EMAIL吧。(以后到我家聚餐，得再多借一些椅子了:))

(代George Yan发)

大家好，好久没有在这里写东西了，想想上次我在这里写blog还是一年多前呢。嘿嘿，好像我的belated new year’s resolution 应该是多写点东西和大家交流吧 :)

回顾2008年，这是对我们的团队来说非常有意义的一年。在产品上，我们发布了Windows HPC Server 2008，而且在十月的SC08上，运行Windows HPC Server的曙光5000A系统以180.6Tf的成绩获得Top500的第十名，引起了这个领域的关注和震惊。 这当然是微软在进入HPC这个领域后在Top500中取得的最好成绩，这个成绩背后的甜酸苦辣我们的丛兰兰同学已经在她的博文里很好的描述了。这次的成绩也引起了中国的媒体的关注，毕竟Windows hpc server 2008 的一部分是在中国开发的, 而且这个成绩不是在那些老牌的cray, ibm机器上产生的，而是在我们中国制造的曙光机器上！有兴趣的同学可以看看媒体对我们评价。

再说说我们的团队，2008年，我们的小团队很荣幸的迎接来了徐明强博士，徐博在这个年轻的团队中是我们的前辈，而且在hpc领域里是个家喻户晓的名字，他曾经是Platform computing 的CTO,加入微软后设计了我们产品中的scheduler 和SOA runtime的架构。很有意思的是媒体对海龟徐也很有兴趣，程序员杂志还专门和徐博做了独家采访(attach link). 最后提一句，徐博回到上海马上入乡随俗，已经成为马路杀手之一，大家看到辆灰色honda odyssey要特别小心，徐博可能就在用着他美国开车原理在上海横冲直撞！:)

附：部分媒体报道：

徐明强博士现任微软中国研发集团服务器与开发工具事业部高性能计算资深架构师，领导HPC产品中的并行编程模型和运行时系统的设计与架构。

徐明强博士拥有21年高性能计算领域专业经历，包括8年学术政府实验室的研究和13年的业界经验。

2004年徐明强博士加入当时成立不久的微软HPC团队，带领了一个跨国团队（雷德蒙和上海）完成Windows Compute Cluster 2003和Window HPC Server 2008地开发工���。

加盟微软之前，徐明强博士在1996年之2004年间担任Platform Computing公司（HPC中间件的领导者）的首席架构师，负责其旗舰产品LSF和Symphony产品的设计和技术战略规划。

1993年至1995年，徐明强博士专注于并行语言的编译和运行是系统的研究，并在阿冈国家实验室完成博士后研究。在此之前，徐明强博士先后在英国埃克塞特大学取得计算机博士学位，在曼切斯特大学担任研究助理员。

我预备写几篇我过去二十一年所见证的HPC发展史。

---------------------------- 

我从事HPC工作已有二十一年，见证了一个完整的并行系统棧被推倒和重建。 旧棧的机器造价高，只有国家实验室可以支付，性价比很差。后来HPC世界有一个大的变更，由微处理器来代替定制的向量机。 现在的各行业成为这个变革的受惠者，变革的结果，使得每一个科学家和工程师，可以付担得起原来只有获取优厚研究经费的国家实验室才能使用的高性能计算机。

这个变革经过二十多年，共三个时期：（1） 专有机时期 （2） 微处理器初期 （3）微处理器盛期。

专有机时期，活跃在市场上的超级计算机公司开发定制化的硬件、软件及开发工具。 微处理器初期，计算机主流公司用精简指令芯片代替了定制化芯片，自开发的定制化网络竞争。到微处理器盛期， 商品化的芯片、标准网络再次把成本降低。 回头看着二十年， 显见有一只看不见的手，要把高性能计算机从国家实验室里推到各个行业、企业。 

在这变更中，我也曾多次更换主攻方向。或者说是从原来的棧上端一直“跌”到下面，如下图所示。

然后，我一级一级的帮助重建并行系统棧.   从这棧“跌”落的原因，是因底层的支持无法能够满足高层的需要，而从底层往高层去的原因，是为了能够使系统能够支持主流的应用和程序员编程的需要。

我记得C++ 的发明者Bjarne Stroustrup 曾说过：“如果某件事值得做，那么这件事值得做两次”。 他曾把这句话用在他撰写的C++ 一书上。 这也是我从事HPC的经历。 到现在为止，我已经重复做了两件事情 （1） 作业调度系统 （2） 面向服务的运行时系统。 将来或许还会再次回到应用层。

（待续）

4月24日到29日，HPC中国研发团队和一些家人朋友，还有现已回到美国工作的前部门经理Alex Sutton，一行22人去了四川省旅游，不仅游览了绮丽秀美的九寨黄龙，还访问了震区都江堰的受灾群众安置点，最开心的是在我家乡的山村小学里见到了好多可爱的小朋友。相信不少朋友都听说过“多背一公斤”这样号召旅行者出行时多背一些物品给贫困山区小孩的故事，而这次把我们的集体旅游与志愿者行动结合起来，则是我们HPC全体成员的共同心愿。成行之前，作为一名积极的志愿者，我推荐了两个选项：去都江堰市龙池镇云华村，捐献旧笔记本电脑协助上海市闸北区热爱家园青年社区志愿者协会（下文简称“热爱家园”）开展电脑培训班，这是我去年曾经实地考察参与了前期调研的项目； 或是访问捐助我家乡县城里大山深处的“夫妻小学”，从我搜到的南充日报报道来看他们的确非常需要帮助。让人喜出望外的是，最后我们不仅去了云华村，大多数的同事还去了我的家乡，好好利用了我们公司的每人每年三天的志愿者假期。我相信我们大多数人都乐于助人，但往往有这样那样的顾虑让我们不能成行，身体力行做个志愿者，并没有想象的那么困难。

24日，从上海飞到成都，我们没时间休息，就汇同热爱家园的职员陈佩赶赴云华村，到了都江堰，“岷江黄浦江水水相融， 上海都江堰心心相连”的大幅标语格外显眼，有名的板房区“幸福家园”显得秩序井然，路边很多楼房的裂缝仍然清晰可见，但更多的是推土机和起重机在热火朝天地重建家园。而我在将近一年的离别之后重访故地，忍不住客串做起了导游，向大家介绍眼前的情景和地震时的故事：这块空地，曾经停放了好多军车搭建了好多帐篷，“铁军来了”、“有困难，找铁军”的横幅格外暖心；那条二王庙后门的公路上，曾经有检疫人员不辞辛劳地向来往车辆喷洒消毒剂；还有多次出现在新闻联播的紫坪铺水库，曾经有无数冲锋舟运走受灾群众，运来物资运来官兵运来希望。

  （多次出现在新闻联播的紫坪铺水库）               （仍在抢修中的龙池隧道）

                （云华村板房区）                                 （搬运物资到板房区）

车开了近三个小时，穿过还在施工中的隧道，开过还在修建的龙池公路，终于到了龙池镇云华村的受灾群众安置点，也就是上海建工援建的板房区，上次来这里调研的时候，我还在上海建工的厨房蹭了几顿饭呢。可能是乡亲们还在劳动，小孩们还在上学，我们并没有见到太多村民，把5台笔记本电脑、若干路由器集线器插线板和长长短短的网线放在热爱家园的云华图书室后，我们走进一家农户，一位大姐和一位老奶奶热情地和我们聊了起来，从她们那熟悉的乡音中，我听到隐隐的伤痛，却流露出更强的坚韧与希望，还有一份真诚的感谢。我们带的东西并不多，也没有时间把网络环境全部搭好，只希望这一点点帮助对即将开展的电脑培训��有些作用。大山里的孩子和青年，急需电脑和互联网来获取信息，学习知识，建设自己的家乡。在返程的车上，我代表四川人由衷地感谢我的同事们愿意大老远地来看看震区，大家都说我太客气了，Ming更是说道：打在手上，全身都会痛，四川人民受灾了，全国人民都心痛。地震过去快一年了，我们见证灾区同胞自强不息重建家园，我们祝福灾区同胞平安幸福安居乐业。

              （等待图书室管理员）                     （村民们搬进板房前的临时居所）

               （Ming与老乡聊天）                         （我们在云华图书室外的合影）

4月28日，游完九寨沟和黄龙的美景之后，超过半数的同事跟我回家乡南充市营山县。不巧的是，连接成都和营山的达成铁路因为扩建施工暂时关闭，于是我们从成都十陵汽车站搭乘客车，耗时4个小时，匆匆吃了午饭，又坐上县团委老师帮我们联系的面包车沿着盘山公路开了2个小时，最后在崎岖的山路上步行了半个小时，到达了我们的目的地合兴乡糖房村大垭口“夫妻小学”。当我们抬着黑板提着礼物走近小学，远远地就听到了小孩子们嘹亮的歌声，心一下子被感动充满了。紧走几步，我看到了眼前的画面，廖老师正领着站得整整齐齐的小孩子们大声唱歌，他们最大的也只是在上二年级啊，歌声轻灵稚气，眼神清澈纯净，笑容天真无邪。还有不少学生家长，围了上来，老乡们不善言辞，但一看就知道是已经站在这里等了我们很久。

         （通往“夫妻小学“崎岖山路）                              （搬运黑板）

        （从附近赶来欢迎我们的小村民）                   （小朋友们唱歌欢迎我们）

老师领着学生们回到教室，幼儿园一个教室，一二年级一个教室。简陋的教室有一面是土墙，有一些大的裂缝，夏天很热，教室光线很暗，廖老师走上教室中间的一张课桌上，伸手拉了开灯的绳索，然后带领幼儿园的孩子们一起念自制黑板上的bpmf拼音，孩子们认真地齐声背诵帮助记忆的口诀“广播电台播播播”(b)，“两个门洞摸摸摸”(m)，窗外的我们和家长都开心地笑了，我想我们都看到了未来的希望。接着廖老师把两个教室的孩子集中到一起，带着他们唱起了一首“爱心叔叔”的歌，我们都很感动，不知道这是不是廖老师自己谱词谱曲的。第一排一个小女孩，长得有点像我的小侄女，我拉着她的手，问“你喜欢读书吗”，她一点也不怕我，也用小手拉着我的大手，扑闪着大眼睛说“喜欢，语文数学我都喜欢”。校长让我们给学生说些什么，因为有的小孩子听不懂普通话，George让我代表大家说说话。而我望着满满一教室可爱的小朋友，和充满期待的老师家长，一时不知说些什么好，他们需要太多的东西，而我们能提供的又太有限。最后我问了一堆问题：你们喜欢读书吗？你们喜欢你们的阳老师吗？你们喜欢你们的廖老师吗？阳老师和廖老师非常地辛苦对吗？我们都要好好学习好不好？得到的则是小孩子们一次更比一次大声的肯定回答。Alex用中文跟打了招呼，孩子们也都兴奋地叽叽喳喳，要跟见到的第一个老外交朋友。最后我们回到教室外的空地，George向校长和老师捐赠了我们带来的物品，大家还当场捐出七千多元，用于教学点的房租等校舍建设。

         （廖老师带领小朋友学拼音）                       （Alex向小朋友问好）

              （”夫妻小学”全貌）                              （教室窗外的学生家长）

       （George代表我们捐款、捐物）

校长和老师承诺会将这笔钱的用途告知我们，而我们每个人离开的时候也在心中思考着这样一些问题：怎么样才可以更好地长期帮助这些老师和孩子呢，如果我们有更多的资源，怎么样才能有效地利用起来呢，目前由我们公司或者个人来直接负责运营是不现实的，是不是有合适的非营利组织可以合作呢？这些问题尚在思考、探讨之中。如果您有意愿、有资源帮助大山深处的老师和孩子，有扶持他们长期发展的推荐方案，我们期待倾听您的声音。

                                                                                                                       魏臻

当金融遇到计算，我们赋予它一个新名词：金融计算。早在20世纪90年代末，纽约、伦敦、日本的诸多金融机构就已经开始了金融计算相关应用，始于1993年全球超级计算机500强排行榜(Top500)中，约450台为国际一流金融机构所用，中国先后已有70多台超级计算机跻身Top 500，但至今仍无一台用于金融领域。

    自2008年以来，上海超级计算中心主任的奚自立先生一直在积极呼吁以打造国际金融中心为目标的上海加紧建设金融计算共同平台，在他看来，“国外同行早已利用金融计算创造出一批批金融衍生产品，并能准确推断出未来走势变化；国内机构还停留在使用HPC简单计算银行信用卡风险，或是通过随机过程分析计保费。”其间的差距恰如大学生与中学生之间的较量。在全球化势头无法阻挡之际，我们能做的只有迎头赶上，否则未来的某一天与国外金融机构真正地同台竞技，也许我们会输得倾家荡产。

高性能金融计算应用三场景

西方金融机构到底如何利用高性能计算提升其核心竞争力？我先举三个简单例子：

案例一：为金融产品高效定价

客户委托金融机构购买期权时，交易员需要快速计算出期权价格。期权价格的计算是要看所在资产（如股票或其他金融资产）的未来走势，这可能需要对上百万甚至上千万种价格走势路径都计算一边。以往，交易员们都是在笔记本电脑上用Excel计算，至少需要几分钟的时间。有了高性能计算后，所有路径可以采用并行计算��整体计算时间被缩短到了七秒钟，客户端计算机也只需16个核，交易员再也不用为需要拖住客户而绞尽脑汁为了。

案例二：更准确评估潜在风险

金融计算容易产生的一个误区是，大家都想算出能赚多少钱，这确实可以算出来，但更重要的是计算投资组合的风险值（value-at- risk），这不仅是对每个头寸重新定价，还要考虑各种参数的变化，例如金融系数、利率、汇率等因素都可能随时改变，这些变化会是一个巨大的组合，再乘上金融组合数，所需要的计算量通常需要花一整晚的时间，最后算出来的报告就是回答一个问题：这么多组合在第二天开市后，价值突然缩水到现有５％的可能性有多大？

案例三：增强快速反应能力，提升程序交易效率

当机构投资者买进大量股票时，往往会分拆成一百、几十股的买，这就要求金融机构的系统能从小小的一百股中发现，哪些来自个人，哪些来自机构，一旦发现有机构出动，就把周围能买到的股票全部买下，然后价格抬高就出货。要让系统做到如此智能，就必须通过神经元网络进行算法训练，其中的难点在于如何算出不同股票持有人之间的关联，不同公司的资产结构有时很复杂，只有大规模的计算才能核算出来。

金融计算离不开数据、模型、计算平台和人

这四大要素中，数据排第一。金融说到底就是数据。相比国内金融行业的严重信息不对称，国外的信息完全开放，所有金融衍生品都会明白告诉客户，它们是怎么计算出来的。中国要发展金融计算，首先要解决数据真源性的问题，然后才能去考虑对数据的分析。谁都知道，针对二十年数据的分析比十年的精确，针对三十年数据的分析比二十年的精确。从现在开始积累我们的真实数据，亡羊补牢，为时不晚。

模型和金融计算平台，不妨借鉴国际上最为主流的模型和技术。随着高性能计算与云计算的结合，金融服务业或可成为这一领域的主流商业应用。在美国，为各大机构提供风险分析服务的RiskMetrics，已经将其计算搬到了云计算平台Windows Azure上，启动初期就已提出6,000个核的需求，是我们之前预期的12倍；为保险业提供精算软件的Milliman，目前也已搬到了Windows Azure平台上。目前欧洲、日本的发展形势非常喜人，与美国相当。

数据、模型、金融计算平台，再加上另一个不可或缺的因素——人才，我们的金融计算就完整了。中国最缺的就是交叉学科人才，尤其在金融领域。为此，我们日前与摩根士丹利和上海超级计算中心联合举办了“微软—摩根士丹利杯”2011金融超级计算挑战赛，即国内首个金融与高性能计算的跨学科竞赛。我们希望通过此次竞赛为金融和计算机等专业的同学提供一个学以致用的平台，也希望以此引起高校、业界和政府部门对高性能金融计算的关注与重视。在为期五天的挑战赛期间，参赛队伍在上海超算中心的曙光5000A超级计算机平台上，运用Windows HPC Server 2008 R2等软件，根据万得资讯提供的金融产品的真实历史数据，对摩根士丹利提供的多种虚拟金融衍生产品进行建模定价与评估，去解决国际金融交易员、风险管理员、分析师每天面对的真实问题。

曾有一位参赛选手在挑战赛论坛上说到，“这几天起早贪黑和高强度的作业，我们理解了更多程序语言的新方法，熟悉了各种期权条款，接触到不���市场股票数据，以及解决问题的基本方法。还有更加体会到市场的无情。” 尤其这最后一句话让我颇有感触，正如《冰与火之歌》中所说的那样“Winter is coming”，惟有无情的市场才能让我们在磨练中成长。

入世十年，中国金融业在规模上取得了长足进步，单论资产规模，中国银行已经位居世界前列；而下一个“十年”，无疑将会面对更加广泛和激烈的国际竞争，中国金融机构如何实现质的飞跃？如何借助高性能计算等尖端IT技术，帮助以上海为代表的中国城市成为国际金融中心？这些悬念，或许要留待通过此次大赛成长起来的一代人，来为我们解开。

徐明强

高性能云计算部门经理

微软亚太研发集团服务器与开发工具事业部

++++

选择并行计算, 被人泼了冷水

1987年春晚，费翔的故乡的云唱红。歌云：“归来吧，浪迹天涯的游子“。可我那时却踏上了留学之路。在研究人工智能高潮时候，我选择了并行计算。为什么要选并行计算呢？ 当时我选主攻方向的标准非常单一，那就是越新越好。我出国的目的就是要学习最新的科学技术，因为当时我坚信只有科学才能救中国。当我把英国导师的研究计划提议书给国内导师过目时，他的第一的评语就是：”我看提议书中的许多参考资料都是当年或近年出的，是国际领先的方向“。

在英国1988年的“并行计算专家会议”上，我遇到一位工业界的人士， 互相介绍时候，我兴奋地告诉他我的博士主攻方向。 他的回答是我一生都不能忘记： “并行计算不会有前途的。将来人们将造越来越大的向量机。没有人愿意将自己的应用并行化，因为太难了”。

现在看来，这个专家是大错特错了。 虽然如此，我还是非常赞赏他的坦率。他完全可以不必加什么评论，事不关己，可以高高挂起。他不愿意看见我往火坑里跳的精神可嘉。不过，专家的话也是要分析地去接受。而且，当你和专家有不同意见的时候，也不要迷信。 长江后浪推前浪，新一代要超过前一代。不迷信权威是科学向前发展必要倡导的精神。

我没有相信他的话。

这段时间的高性能计算的生态环境如下：

我们看见，“定制”“专有”这是造成价格天价的原因。 那时候，CRAY只有少数西方的国家实验室和大型制造业公司才能拥有。 只有少数先进国家才能拥有。杜甫一句诗词，似乎表达了我当时的意愿并有预言性：“安得广厦千万间，大庇 天下寒士俱欢颜”。 高性能计算关乎全世界的一项技术，它的益处不能被一个国家所禁锢和独占。这二十一年，我感觉有支看不见的手，把高性能计算机从国家实验室的围墙里，推出到制造业，电子业、生命科学和制药业，石油业，金融业。 从美国、推向西方先进的国家，又推向东方。 曙光和微软研制的两百万亿次计算机就是一个例子。

小心处理器杀手

在一九九零时候，美国劳伦斯Livermore 实验室的Eugene Brooks 说了一句话：“Beware the killer Micros” (小心微处理器杀手)。 他这句话叫许多向量机的生产和设计厂商诚惶诚恐，为什么呢？ 我在微软一个同事，Frank Chism, 曾经是Cray 的雇员。他告诉我，那时候每年CRAY的CEO和克莱斯勒的CIO的谈话是非常痛苦的。 克莱斯勒的CIO就问CRAY的CEO：为什么HP的工作站比你们CRAY要快，而我却要支付更贵的机器呢？“。 微处理机的日益强大的性价比使之取向量机而代之的成为必然。

给我泼冷水的英国专家有句还是说对了，那就是并行化一个程序是很困难的，为什么别人会有人去做呢？不过他的话有个逻辑谬误，那就是：“没有人会去修改应用，因为太困难了“。 出力不讨好的事尚且有人做，更何况出力能讨到好的事情呢？这时候，美国制造业的一个企业，就成功地用工作站替代了向量机来解决计算流体力学的问题。我们下次再聊。

对于专有机的Occam语言的三大遗憾

Occam 语言是我接触并行计算的第一个语言。这个语言是以一个哲学家Occam命名。提起他，我们都知道有个Occam剃刀原则（Occam Razor）。 就是：“Keep it simple” 原则。这个语言之简练和直观不逊于其命名。它用Channel, SEQ, PAR 和ALT 等语言部件，可以构建各种并行进程及其通讯和同步场景. 下面程序实现了典型的生产者和消费者通讯的例子：

PROC producer (CHAN INT out!)

  INT x:

  SEQ

      x := 0

     WHILE TRUE

         SEQ

             out ! x

             x := x + 1

:

PROC consumer (CHAN INT in?)

    WHILE TRUE

       INT v:

       SEQ

           in ? v

           .. do something with `v'

:

PROC network ()

    CHAN INT c:

    PAR

       producer (c!)

       consumer (c?)

:

我自然是被这个语言着迷。可惜好景不长，我立刻发现Occam 语言的三个局限：

遗憾一： 并行进程的静态、编译时决定的。不可能在运行时动态产生进程：

PAR I = 1 to N

    Process (I)

这里Ｎ必须是编译时就确定的常数。这样对编写通用目的程序库带来很大的麻烦。 就好比MPI 用户没有办法根据MPI Rank 和MPI_Size 来动态划分域，只能硬编码其处理单元数量，那么今天恐怕还没有Nastran 等ISV通用库。 和我一起做博士的某英国哥们，他曾说要解决这个问题。我一直很感兴趣，不停地问他技术细节，结果他说了半天，我还是不清楚。说句实话，到今天，我还是没有明白。 后来这个哥们找到了工作，放弃了博士。

到了后来1996年，MPI-2制定的时候，我参加了关于动态创建进程的讨论。当时我已经加入了Platform Computing 作LSF， 可是这些MPI专家们对于如何映像进程到处理机的理解不够透彻。他们没有认识到，动态创建必须基于一个资源管理的调度系统。 而他们没有有效地将需求及时提供给作业调度厂商。结果，现在有许多的MPI2 动态创建进程的实现，但是没有哪个是和著名的作业调度器集成的。 原因就是，大部分作业调度器的资源分配是静态的。一旦资源分配后，就无法改变。到了Windows HPC Server起步在2004 年的时候，我设计作业概念就考虑到作业当能伸能缩的. 因此，Windows HPC Server 是为数不多能够支持MPI 2的作业调度系统。

遗憾二： Channel 是没有缓冲的。一个发消息的进程，如果对方不在受的时候，就会被阻。直到有接受消息的。开始还觉得没有什么，结果不知道多少看起来不会死锁的代码，结果给死锁了。比如，两个进程计算后相互交换结果如下，就会死锁。

PROC left (CHAN INT toRight!, CHAN INT fromRight)

    … compute

    toRight ! localResult

    fromRight? neighborResult

:

PROC right (CHAN INT toLeft!, CHAN INT fromLeft)

    … compute

    toLeft ! localResult

    fromLeft? neighborResult

:

CHAN INT c, d:

    PAR

    left (c!, d?)

    right (d!, c?)

原因就是，对于left 进程，toLeft! localResult 会被阻塞，因为right 进程还没有接收消息 。 right进程也同理被阻塞。现在同学们用MPI的时候，已经对于MPI 库中所提供的消息缓冲区习惯了.  当我发现此功能后，顿时心存感激。

遗憾三：进程和物理处理机之间的映射是静态的

这是一个致命的局限。如下所示，进程terminal, editor 和network 是在编译时被硬性映像到不同的处理机上。

PLACED PAR

  PROCESSOR 1

  terminal (term.in, term.out)

  PROCESSOR 2

  editor (term.in, term.out, files.in, files.out)

  PROCESSOR 3

  network (files.in, files.out)

对于这个局限的极度不满，心中涌出强烈的愿望想要解决这个问题。人生很有意思，９年后，我终于开始解决这个问题，一作就是近十二年。这个问题就是如何应用动态映射处理机，就是作业调度器（Job Scheduler）的灵魂.

（待续）

Speed beats beauty

并行机在专有机时代分两大阵营，共享内存和分布式内存结构。

共享内存所提供的编程界面是非常优雅的。分布式内存机器的编程界面是基于消息传输库，不够优雅。串行程序的并行化相对容易的多，因为任何一个线程都可以访问到所有的数据，因此不需要对原来串行程序在结构上作大的改动。 而为分布式内存机器写程序却不同，首先应用域的数据就要分块，每个进程不光需要本地数据，还要边界数据。在本地计算完后，还要和邻进程交换数据。程序结构上要做大改动。

共享内存最大的缺陷是物理上的。是因为其扩展性差。当时80年代的处理机是很慢的了，可是到了32个就出现瓶颈。 这无法能够满足美国能源部许多宏大挑战性问题（Grand Challenge Problems）。所以当时分布式内存的拥护者流行的一句话就是：“Speed beats beauty”。

一个很自然生发的美好愿望就来了：能不能使用物理分布式内存，在其上建立共享内存的界面。 这样我们不是就取两者精华去两者之糟粕吗？ 分布式共享内存（Distributed Shared Memory – DSM）这样的机器就成为了专有机时代最后一个大创举。

这个基因杂交出来的机器却有致命性的DNA缺陷。我一九九一年加入了曼彻斯特大学新奇计算中心 (CNC) （Centre for Novel Computing） 在John Gurd教授下作研究员。John Gurd 是数据流机器的知名学者。

我加入后不久，CNC就拿到一笔科研补助金（research grant) ，Gurd 教授在诸多的专有机厂商中挑选了一个Kendal了 Square Research (KSR)。其用意在于这个中心的名字里有个“新奇”。九十年代初的英国，爱丁堡和不利索托（Bristol）的中心里有不少大型专有机。绝大部分都是分布式内存。所以，Gurd教授觉得再买一个属于重复。正好KSR 是一个分布式共享内存的机器。这也就给了我一个和这个杂交机器零距离接触的机会。在这个机器上可以用标准的Pthread库，可以用锁来同步对于共享内存的访问。操作系统自动将不同线程分布到不同的节点上。而节点之间的操作系统实现了定制的多机内存的一致性协议。这样编程的确简单了。 机器及软件环境的细节大家可以参考维基百科：http://en.wikipedia.org/wiki/Kendall_Square_Research。 恕不赘复。

我当时对于这种新奇机器是充满热忱。在短短半年内，我移植了许多并行逻辑和功能性语言（Parallel Logic and Functional language） e.g. Strand, PCN 等。我之所以能够很快地移植这些语言，是因为共享内存不需要对程序结构有大的改动。

那么KSR致命DNA弱点在哪里呢？就是性能和扩展性差。为什么物理分布内存还会有性能和扩展性问题呢？

首先，它是在硬件和操作系统实现内存缓存一致性协议。为此它的RISC 芯片是专有定制的。这就意味着它无法和业界的豪门IBM, Sun, SGI, HP等RISC 芯片的性能匹敌。第二，也就是最关键的, 这点还是后来我加入Platform Computing后和公司的ＣＥＯ周松年聊起后受的启发。周松年说：“DSM 在性能上无法和消息传输库并行化的比拟的原因是，DSM的管理单元是进程的地址空间的页(page)，它无法反映应用对数据的访问情况（access pattern）。而消息传输库使程序员能够充分利用应用对数据访问的知识来优化并行算法数据访问的局部性（locality）“。 他的透视使我顿悟。缺乏对于应用访问数据的知识，就无法优化对于数据的访问的局部性。 分布式内存的机器造成了多层内存（本地和远程内存）状况，影响应用性能最大的因素，就是是否能够极大限度地访问本地内存。

自KSR 破产后，我再没有看见过一个DSM的机器。

（待续）

逃匿MPI进程

1993年我加入阿冈国家实验室数学和计算机科学部做Ian Foster 的博士后。

Ian 告诉我，现在科研经费的要求和实际实用应用相结合。为此，我们不能再搞什么logic / functional 语言了。必须和Fortran/C有关。 此时他发明了一个新的语言Fortran-M (M- 代表message passing)。 这个语言实在太像Occam了。Occam 里有Channel， Fortran-M 叫port. Occam的Channel 是强类型的，Fortran-M Port 也是强类型的。Occam 里有Process，Fortran也有，并且，Process可以动态产生！

Source:

我为这个语言写了编译器。Steve Tuecke (后来的globus 架构师)和Bob Olsen写了运行时系统。我倒是非常享受这个项目。那时的我，就是喜欢往系统栈的底层钻。当时的我，觉得世界上没有任何其他的研究比创建并行语言的编译和运行时系统更有吸引力。我当时觉得，并行计算的栈MPI 已经差不多完善了。而并行语言和运行时系统将是把并行计算推向主流的关键技术。

不过，一件事情改变了我的看法。

一次，我正在做MPI 和Fortran-M 的性能比较实验。结果Rusty Lusk来到我的办公室。满脸不悦。他说我在他的机器上运行了一个MPI 程序，使他的机器非常慢。问我是否可以杀掉它。我觉得很奇怪，我是用了他的机器跑了mpirun. 不过我已经Ctrl-C停掉了我的mpirun。怎么还会在他的机器上跑呢？ 后来才知道，他写的MPIRUN是使用rsh 在远程机器上启动MPI 进程。Rsh可以将远程进程的stdout, stderr 转到客户端，使用户有个透明的感觉。但是，当用户键入Ctrl-C 的时候，只是把mpirun 进程杀掉，而远程的进程就逃匿了。 不光没有被杀掉，而且在背景里跑得非常欢。 结论是，Rusty是“自食其果”。

我搜索了网络，发现这种逃匿MPI进程（Runaway MPI Processes）是许多超级计算机中心中造成极大的破坏。用户总是抱怨，怎么超级计算机越用越慢！其实都是因为每次mpirun 非正常中断后，在远程节点就会有逃匿进程出现。管理员最头痛地就是要时不时地登陆到几十个甚至上百个节点上去清除这些逃匿进程。

后来当我加入Platform Computing时候，周松年问我能为MPI做什么？我就说我要解决逃匿进程问题。在１９９６年我花了半年写了一个Parallel Application Support Software. 能够完全解决逃匿进程，并且还能精确地采集计算资源使用数据。后来成为公司LSF Parallel产品。

今天您使用HPC服务器的MSMPI，您也不会发现逃匿进程。这就是投入生产使用的运行时系统和学术界软件的区别。 这点，我们必须归功于那次Rusty Lusk和我的小小的不愉快。这点小不愉快，让我开始关注到许多用户因受MPICH的启动方式而导致的逃匿进程之苦。