HPC，相约TechEd 2009

2009年微软技术大会（TechEd）中国下周就将在北京召开了，服务器与开发工具事业部的中国研发团队将派出31位项目经理、软件设计开发工程师和软件测试开发工程师，与中国程序开发者和IT从业人员分享我们最新的产品开发。以下是HPC相关的课程和专家交流沟通会环节，徐明强博士将在大会现场与大家面对面交流。

课程：11/6, 13:00-14:10 使用Windows 高性能计算服务器高效提速应用(WSV331)

您的应用中的算法和商业流程是否包含众多独立计算单元而需要冗长的处理时间？您当欣慰是这些应用是高性能计算应用范例。在此讲座中，您可以了解如何使用Windows WCF 和Windows 高性能计算服务器2008 来对此类应用进行多个数量级的提速。 我们将着重演示讲解高性能计算编程模式能够简便地、高效地将客户端应用的计算单元负荷卸载到强大的集群上，以达到可扩展性的提速功效。

专家交流沟通会：11/6, 15:50-16:35 微软高性能计算在金融和制造业的行业应用(MST006)

本沟通会将和大家探讨如何利用微软的高性能计算平台提高金融行业和制造业的生产率。

Visual Studio 2008 HPC SOA C# 调试器插件

就在这个月，负责微软Developer Devision工作的微软全球副总裁Soma先生写了一篇博客介绍Visual Studio 2008和即将发布的Visual Studio 2010中支持并行程序开发的一系列工具。在这篇博客（中文翻译版）中，Soma先生不仅介绍了用于开发MPI程序的MPI debugger，还介绍了用于开发Windows HPC Server 2008中集群面向服务架构(Cluster SOA)应用的SOA Debugger插件。在我们前面一篇博客中已经对MPI Debugger的功能做了介绍，其实SOA Debugger也是我们小组努力工作的成果。通过本篇博客，我想请大家和我一道预览即将发布的HPC SOA C# Cluster Debugger插件。

大家知道集群面向服务架构是我们随Windows HPC Server 2008的发布而新推出的并行应用架构和编程模型。通过集群面向服务架构，我们可以把原先运行在单机上的WCF应用扩展成运行在`Windows HPC Server集群环境中的并行应用。要创建一个SOA应用程序大致上需要经历以下的三步：创建服务（WCF Service）；将服务部署到集群中；创建客户端应用。如果我们想调试包括客户端和服务在内的整个应用，还要加上如下的步骤：1）在运行服务的计算节点上安装并运行远程调试器（msvsmon.exe）；2）在Visual Studio中运行并调试客户端程序；3）在SOA会话（SOA Session）被创建以后，将Visual Studio调试器附加（attach）到计算节点上的服务宿主进程（HpcServiceHost.exe）上从而调试服务进程。这样调试一个SOA应用一共需要3+3=6个步骤，这还不包括每次修改服务的代码还需要重新执行服务部署的过程。听上去是不是很复杂？别急，下面随我看看SOA Debugger如何为你简化SOA应用开发和调试的体验！

安装SOA Debugger插件后，在Visual Studio的新建C#项目的对话框中，我们看到了一个新的项目类型：SOA Client。没错，就是它了！

建立一个SOA Client项目并把它命名为MySOAClient。在我们研究这个新项目之前，还是让我们进行SOA开发的第一步：创建服务程序。大家知道SOA服务程序其实就是一个WCF服务，你可以把现有的WCF服务项目添加到刚刚的MySOAClient解决方案中，也可以在这个解决方案中新建一个WCF服务项目。在我的示例中，我在解决方案中新建了一个叫“EchoService”的简单WCF服务。在创建完服务之后，让我们跳过下一步“将服务部署到集群中”，因为下面我们将看到SOA Debugger可以自动帮我们完成服务部署的工作。

下面让我们回到客户端项目来创建客户端应用程序。大体上编码SOA客户端程序和编码普通的WCF客户端程序比较类似，在此就不一一赘述，具体信息大家可以参看Cluster SOA架构白皮书。客户端编码完成之后，我们还需要对项目的一些属性进行设置才能进行集群上的调试工作。在Visual Studio的解决方案浏览器中右键点击MySOAClient项目，点击属性打开项目属性页面，如下图，

我们可以看到这个项目比一般的C#项目多了一个SOA Settings的属性标签。在SOA Setting的属性页中，我们首先在Head node下拉列表中选择我们的集群头节点名。这里的头节点名必须与我们在客户端代码中创建的会话启动信息相一致。比如在我的代码中，

……

SessionStartInfo startinfo = new SessionStartInfo("SHPC-0052", "EchoService");

……

于是这里我就选择头节点为“SHPC-0052”。接下来我们需要在Available service列表中勾选需要调试的WCF服务。在这个列表中会列出当前解决方案中的所有WCF服务类型的项目，我们只需要选择客户端代码调用的服务（或者多个服务）即可。这里的服务名和服务项目名称以及会话启动信息中的服务名都应该是相同的（在这里是“EchoService”）。除了头节点名和被调试的服务以外，其他的属性都有合适的默认选项，我们暂时不要改变它们的设定。好了，调试的准备工作全部完成了，让我们开始调试吧！

首先将MySOAClient项目设置为调试的启动项目，随后我们在客户端程序创建SOA会话（Microsoft.Hpc.Scheduler.Session.Session.CreateSession(startinfo)）的代码后放置一个断点。按“F5”启动调试器，MySOAClient程序会运行到CreateSession()之后中断。这时SOA会话以及SOA服务job已经创建完成了，让我们来看一看Visual Studio是不是已经附加到所有的服务进程上。从调试菜单打开进程工具窗口，我们可以看到，

Visual Studio调试器已经附加到所有的服务宿主进程上。WCF服务部署，远程调试器的启动以及附加远程进程的工作都被SOA Debugger自动完成了，是不是有WOW！的感觉呢？既然我们已经完成了服务进程的附加步骤，我们就可以直接调试WCF服务的代码了。所有现有的调试器功能我们都可以使用，包括在在服务代码的断点上中断，F10/F11的单步调试，表达式求值（Watch）以及条件断点等等。当调试结束后，SOA Debugger还会自动完成服务的清理工作。

我们已经完成了整个SOA开发/调试的过程，回头看看是不是很简单呢？原先的六个步骤最终被简化为：1）创建服务；2）创建客户端程序并设置SOA调试选项；3）F5！这三步，是不是很简单呢？

以上就是对SOA Debugger的简介，SOA Debugger中还有很多很cool的功能，包括：调试不在Visual Studio解决方案中的WCF服务； 为被调试的服务部署额外的文件；只调试运行在特定计算节点上的服务；只调试某些特定的服务请求（Service Request）。对于这些功能我就不一一介绍了，我期待你试用我们即将发布的SOA Debugger之后自己亲身体验所有这些实用的功能！我们的开发工作还在进行之中，在最终发布之一定还会有一些改动，如果大家有什么意见或者问题，欢迎回帖。谢谢！

Ps.，Visual Studio 2008中的MPI Debugger 插件已经发布了，欢迎大家从这里免费下载使用。Visual Studio 2010中的MPI Debugger将随Visual Studio 2010发布，敬请期待。

高性能计算系统栈的推倒和重建 （四）微处理机初期 （二）逃匿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的启动方式而导致的逃匿进程之苦。

高性能计算系统栈的推倒和重建 - 专有机（二）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的机器。

高性能计算系统栈的推倒和重建 （三）微处理机HPC初期 A

望洋兴叹

在专有机时代作并行计算的研究，你得会投“胎”。当时，全球科研的浪尖是在美国，能在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 的一个不开心遭遇引发我的奇想。

高性能计算系统栈的推倒和重建 （二） 专有机时期

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

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）的灵魂.

Visual Studio 2010 Beta1 中的 MPI Cluster Debugger

在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正式发布之前可能还会有一些改动。若大家有什么建议，欢迎回帖。谢谢！

旅行中的志愿者

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                                                                       魏臻

高性能系统棧的推倒和重建 (一)

徐明强博士现任微软中国研发集团服务器与开发工具事业部高性能计算资深架构师，领导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） 微处理器初期 （2）微处理器盛期。

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

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

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

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

（待续）

我们上人民日报了:)

(代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要特别小心，徐博可能就在用这他美国开车原理在上海横冲直撞！:)

附：部分媒体报道：

我组喜获年度最佳客户关怀奖

          服务器与开发工具事业部（中国）上个月举行了热闹的新年晚会。除了吃好喝好，欣赏到了同事们精彩搞笑的节目(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吧。(以后到我家聚餐，得再多借一些椅子了:))

如何测试资源分配—失败及恢复

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

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

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)中国团队测试开发工程师

加入Windows HPC Server 2008 微软客户体验改善计划(Customer Experience Improvement Program)！

您想帮助我们一起改进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产品非常有价值！:)

亲历北京Top 500

金秋的北京，一年中难得的好天气，人们还沉浸在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 下围棋得了世界冠军！

今年10月在北京举行第13届国际计算机棋类奥林匹克大赛上，经过激烈的角逐，程序Many Faces of Go以全胜战绩囊括了围棋项目19×19和9×9两个棋盘规模级别的冠军！而为这一世界冠军围棋程序提供超强马力的，正是运行在四台八核计算机上的Windows HPC Server 2008系统。这配备了高性能武器的32个核，果然不负众望，打败了拥有更多核的法国劲敌MoGo。

(本图片来自http://www.grappa.univ-lille3.fr/icga/tournament.php?id=181 屏幕截图)

故事是怎么开始的呢?话说我们组美国的两位工程师在公司走廊里侃大山，聊到国际象棋问题现在已经差不多解决了，一台笔记本电脑都可以“欺负”世界冠军卡斯帕罗夫了。但是围棋却要复杂得多(棋盘更大，可行的着法更多，局势判断更复杂)，要很强的计算能力才能勉强跟一个业余选手抗衡。要是能用我们的产品帮助开发人员写游戏程序去冲击计算机围棋届的奥林匹克大赛，想必相当好玩。光说不练假把式，我们的工程师随即联系了Many Faces of Go程序的作者David Fotland，稍加讨论，双方一拍即合。经过移植、调试和优化，一个基于MSMPI的集群版Many Faces of Go诞生了，一个新的计算机围棋程序世界冠军诞生了。

更精彩的是，我们为这个围棋程序开发了Surface版本！（什么？你还不知道Surface?赶快看看这张神奇的桌子吧，无数人，包括我，都梦想把它摆在自己家的客厅呢，虽然可能会超出装潢预算）在刚刚过去的微软专业开发者大会PDC和超级计算大会SC08上，这一Surface围棋程序演示都吸引了好多好多的眼球，好多好多的WoW，不信？看看这段超酷的视频http://www.youtube.com/watch?v=Qe0o-IvHOa0 吧。

下图为超级计算大会SC08的微软展台，我们组的一位法国工程师正在做一件我们都很喜欢做的事情——跟四台机器下围棋。每落一子，就看看我们自己开发的Heat Map（即Windows HPC Server 2008中的热图功能，参见下图Surface上的显示器）显示这些机器的CPU都biu的一下上去了，集群吭哧吭哧地开始算起来，后台程序还能告诉我们它尝试思考了下一步走哪些地方，几秒之后它选出觉得胜率最大的一招后再得意地落下棋子，CPU就又biu地一下凉快下来。联想到我见过的随温度变化而变色的茶杯，如果用茶杯来反映CPU的忙碌情况，当两台计算机纹枰论道，只见两个茶杯涨红了脸冥思苦想，应该相当有趣:)