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 Razor）。 就是：“Keep it simple” 原则。这个语言之简练和直观不逊于其命名。它用Channel, SEQ, PAR 和ALT 等语言部件，可以构建各种并行进程及其通讯和同步场景. 下面程序实现了典型的生产者和消费者通讯的例子：
PROC producer (CHAN INT out!)
INT x:
SEQ
x := 0
WHILE TRUE
out ! x
x := x + 1
:
PROC consumer (CHAN INT in?)
INT v:
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)
toLeft ! localResult
fromLeft? neighborResult
CHAN INT c, d:
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）的灵魂.
（待续）