编译器发展史

注：本文为编译器相关的两篇文章合辑。

---

编译器的「五个十年」发展史

云头条 2018 年 11 月 03 日 23:26

作者：自 20 世纪 70 年代就读伊利诺伊大学研究生院以来，Michael Wolfe 就一直主攻并行计算方面的语言和编译器。在此过程中，他与别人创办 Kuck and Associates（已被英特尔收购），在俄勒冈州研究生院（自与俄勒冈健康与科学大学合并以来）投身学术界，并在 PGI 开发高性能 Fortran（PGI 先被意法半导体收购，最近被英伟达收购）。如今大部分时间，他在一个为高度并行计算、尤其是为英伟达 GPU 加速器开发和改进 PGI 编译器的团队担任技术主管。

如果想了解我们在计算机架构和驱动计算机架构的编译器方面的现状，有必要看看编译器如何在六十年间由一种架构改用另一种架构。

先让目光回到 1957 年的第一个编译器 IBM Fortran。这是一项了不起的技术。如果你看看它的起源和取得的成果，付出的巨大努力是今天的人都无法想象的。

IBM 想要销售计算机，想要销售让更多的人能够进行编程的计算机。当时编程是用汇编语言完成的。这太难了，IBM 很清楚这一点。于是蓝色巨人希望人们有办法更快地编写程序，又不牺牲性能。Fortran 的开发人员（指发明 Fortran 的那些人，而不是发明使用编译器和语言的程序的那些人）希望利用如今所谓的高级编程语言编写的程序，提供尽可能接近手动调整的机器代码的性能。

说到编译器，你必须考虑三个 P：性能、生产力和可移植性。Fortran 的发明者拿机器代码的性能作了比较。生产力方面的好处是，程序员再也不必编写机器代码。我不知道 IBM 在可移植性方面的最初意图，不过你在 1957 年无法为软件获得专利权，IBM 也没有抱怨其他企业组织实现 Fortran。因此没过多久，市面上出现了来自其他供应商的面向其他机器的 Fortran 编译器。这立即为 Fortran 程序提供了机器代码无法想象的可移植性。

从这一刻起，编译器开始迅猛发展起来。让我们看看每个十年的情况。

第一个十年

在 20 世纪 60 年代（就在我出生前），计算机架构师和编译器编写者首先开始考虑并行性。即使那样，人们仍然认为计算机速度不够快，速度提升也不够快，觉得并行性有望解决这个问题。我们看到指令级并行性引入到了 Seymour Cray 公司的 CDC 6600 和 CDC 7600 以及 IBM System/ 360 Model 91 中。更为激进的做法是开发出了由伊利诺伊大学的研究人员设计并由 Burroughs 公司制造的 ILLIAC IV、Control Data Corp STAR-100 以及德州仪器（TI）Advanced Scientific Computer。CDC 和 TI 的系统是内存到内存的长向量机，而 ILLIAC IV 是我们今天所说的 SIMD 机器。ILLIAC 之所以功能有限，是由于没有主要的标量处理器，编程起来确实很难。面向 STAR-100 的 Fortran 编译器添加了用于描述长连续向量操作的语法。TI ASC 机器最值得关注，因为它拥有第一个自动向量化编译器。TI 做了一番了不起的工作，确实提升了当时编译器分析的最新水平。

第二个十年

20 世纪 70 年代，Cray-1 成为第一台商业上大获成功的超级计算机。它有众多的跟随者和模仿者，许多读者可能了如指掌。Cray 机器的成功很大程度上归功于引入了向量寄存器。就像标量寄存器一样，向量寄存器让程序可以对小小的数据向量执行许多操作，没必要从内存加载和存储到内存。Cray Research 还开发了一种非常大胆的向量化编译器。它在许多方面与早期的 TI 编译器类似，但 Cray 编译器拥有让它非常备受关注的附加功能。其中最重要的一项功能是能够为程序员提供编译器反馈。

如今开发人员编译程序时，如果程序含有语法错误，编译器将生成出错消息。程序员不断修复这些错误并重新编译，直到拥有一个正常运行的程序。如果开发人员希望程序运行得更快，可以启用编译器优化标志，好让生成的可执行文件运行得更快 —— 他们希望如此。在大多数计算机上，优化代码和非优化代码之间的性能可能相差两倍，通常差异小得多，比如相差 10%、20% 或者 50%。与之相比的是原始 Cray 机器上可用的向量指令集。在这种情况下，代码被 Cray 编译器优化和向量化后，程序员常常会看到性能提升 5 倍到 10 倍。程序员、尤其是高性能计算（HPC）程序员愿意做大量工作，以便将性能提升 5 倍或更高。

来自 Cray 编译器的反馈将告诉程序员它在第 110 行向量化了一个循环（loop），在第 220 行向量化了另一个循环，但是没有在第 230 行向量化循环，原因是第 235 行有无法被向量化的 I/O 语句或函数调用。或者，可能存在编译器无法分析的数组引用，或者某个数组的第二个下标中的一个未知变量阻碍了依赖项分析，因此该循环无法进行向量化。想要获得向量性能的 Cray 程序员格外注意这些消息。他们根据这种反馈修改了代码，可能从循环中取出 I/O 语句，或者将循环推入到子程序，或者修改数组引用以删除某个未知变量。有时他们会添加一个编译器指令，以便向编译器传达可以安全地进行向量化这一信息，即使编译器无法通过依赖项分析来确定这一点。

多亏了编译器的反馈，发生了三件事。

首先，更多的程序被向量化，更多的程序员得益于 Cray 向量性能。其次，Cray 程序员受过了培训，不再将 I/O 语句、条件语句和过程调用放入到循环的中间。他们明白一个步长（stride）的数据访问很重要，确保内部循环中的数组访问是一个步长。第三，用 Cray 编译器自动向量化的程序可以在来自 Alliant、Convex、Digital、富士通、日立、IBM 和 NEC 的许多类似的向量机上重新编译。所有这些系统都拥有带向量寄存器的向量处理器和自动向量化编译器，之前针对 Cray 优化的代码在所有这些机器上都可以进行向量化，并很顺畅地运行。简而言之，Cray 程序员终于实现了性能、生产力和可移植性这三个目标。

这个编译器反馈有多重要、培训整整一代 HPC 开发人员为向量机编程有多成功，怎么强调都不为过。每个使用它的人都很高兴。那时候，我还在伊利诺伊大学，我们考虑开一家立足于并行化编译器技术的公司。当然，我们的技术比别人的要好࿰