高性能计算系统栈的推倒和重建（二）

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

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

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

我没有相信他的话。

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


机器厂商   Cray, Thinking Machines (CM-5), Sequent, Kendal Square Research (KSR), INMOS (Transputers)

硬件   定制化的芯片

处理器间网络联接   定制化的网络

软件   专有语言或FORTRAN的专有指令和工具



我们看见，“定制”“专有”这是造成价格天价的原因。 那时候，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的机器。