科学计算编程中的Fortran

1、科学计算编程中的 Fortran科学计算编程中的 Fortran 与C+之争自从有了程序设计语言，“哪种编程语言好就成为了亘古不变的话题。这个问题一 经提出，必然会招来一场巨大的口水仗。作者曾经在某些论坛上提出了类似“ Fortran 和 C+那个用的多之类的问题，回帖全部达几十个以上，各种意见针锋相对，犹如Fortran和C+信徒之间的“圣战"一般好看。有很多人曾经请 C+语言之父Bjarne Stroustrup 做一个C+与其它编程语言的比拟, 而 Stroustrup 明确的拒绝了。他指出，从技术上讲，一个所谓的“公平的比拟将会涉 及到大量的技术，这是一个工作量巨大的任务，绝

2、对不是简单的用C+和其它语言写同一段代码然后比拟其运行时间就能完成的。这种比拟涉及到具体的应用领域和用户需求，所 处理的信息类型，编译器的质量不同语言的编译器开发的投入是有相当大差异的，程 序员的水平与“偏好，编程语言的标准如究竟是C+97与Fortran90比拟，还是应该C+0x与Fortran2021 比拟？等等。他甚至认为，这种比拟是“ rarely meaningful "的1 。因此，今天作者也不打算为某种编程语言摇旗呐喊，而是仅就科学计算编程领域，特 别是，限于作者专业即量子化学和分子模拟，来谈一谈两大“主流编程语言：Fortran和C+的在理论化学界的应用历史，以及某些

3、人包括作者对它们的看法。1 Fortran 的美好时代毋庸置疑， 1957 年出现的 Fortran 是世界上第一个高级编程语言。它的出现，大大 降低了普通科研人员学习编程的门槛，而且增强了代码的可移植性。在此之前，人们都是 用机器语言直接书写程序，这种语言对于一般人而言难度太大了，而且是与运行机器相关， 因此很难写出高效且具有可移植性的程序。例如， Roothaan 在研究原子自洽场的计算时专门为 IBM 7030 数字计算机写了一些程 序，这些程序用来优化 Slater 基组已经 10多年了。不幸的是，由于该程序是完全使用 IBM 的机器语言所书写，因此在 20世纪 60年代，当这种机器逐

4、渐消失时，这些程序逐渐 成为了废品。意识到这个资源的重要性， Clementi 及其同事决定把这些程序用 Fortran 全部重写，并且增加了处理 Gauss 基组的功能 2 。这段代码从此复活，成为了量子化学 程序库中一个重要局部。Fortran 语言的重要性从此被理论化学家所知。它的优点几乎数不胜数。首先，它的 语法简单，任何一个理论化学的研究生几乎一天就能学会，可以迅速用它开展工作；其次， 它的运行效率极高，不要说现代编译器如 GNU Fortran 或 intel Fortran 编译器，就 是世界上第一个 Fortran 编译器都可以将其每一语句都翻译成几乎没有冗余的、效率至少 不低

5、于手写的机器码；第三， Fortran 代码具有可移植性，与机器无关。很快，在 20世 纪7080年代，一批批量子化学程序如雨后春笋般出现，如早期的Gaussian ,Polyatom，以及后来的GAMESS NWChen等等，几乎全部都是由 Fortran77编写的。Fortran77 在量子化学领域绝对是功不可没，它为普及和开展量子化学做出了巨大的奉献。 那个时代， Fortran77 是很多自然科学研究生的必修课。自此， Fortran 成为了数值计算领域的“主流语言。2 C 语言的崛起20 实际 70年代， C 语言逐渐崛起。这个语言是为了编写 Unix 操作系统而开发的。 很快，这种

6、“半汇编性质的高级语言，由于其具有极其灵活的控制机器的能力而深受计 算机专业人士的喜爱。不过，由于其学习难度较之 Fortran 稍高，而量子化学以纯粹数值 计算为主， Fortran 足以满足要求，因此 C 在量子化学领域没有什么明显优势，因此大多 数量子化学家对其不感兴趣。此时， C 和 Fortran 处于“井水不犯河水的状态。而 80 年代左右，分子模拟科学开始开展。由于分子模拟的流程相对复杂，Fortran77语言在实现某些功能时稍显繁琐，如对某些配置文件进行语法分析，一些模式识别和人工 智能过程等等，此时 C 语言的优势开始显露，大量分子模拟领域的研究组开始用 C 开发 程序，如分

7、子对接软件 Autodock 等等。 Fortran 垄断地位的打破，说明理论化学领域编 程语言之战的种子已经悄然的埋下。3 理论化学软件开发的瓶颈在任何软件开发领域学术界还是商业界，前人留下的代码库都是无比珍贵的财富。 因为无论程序员的水平有多高，代码毕竟是一个字一个字的敲进去的。比方矩阵乘法这种 通用的操作都需要每次重新写，那会浪费大量珍贵的人力财力。在前人的根底上开发新的 功能，是大型软件开发的通用规那么。量子化学自 60 年代以来，积累了大量的 Fortran 程 序库，它们的开发都是非常艰苦的，是无数量子化学家智慧的结晶，每个研究组都要在前 人的根底上继续的研究，例如现在的 Gaus

8、sian09 里面还使用着当年 Pople 亲手敲进去的 代码。不幸的是，到了 90 年代，这种长期的积累，既是这个组的财富，同时却也是软件继 续开展的一个致命的阻碍。这些开发于 60 年代的量子化学程序，几乎都是“无组织无纪 律的开发的，根本没有料到后来的开展程度。因此，很多组逐年积累达万行的程序，几 乎毫无任何代码美感可言：变量命名难以理解我见过一个 Ewald 求和程序里面充满着 p ， pp ， ppp 这样的变量名，逻辑结构杂乱无章 goto ， if 之类随意嵌套。维护 人员在阅读以前的源码时需要消耗大量的精力，而这是一个痛苦的过程。早期的量子化学 程序都有大量的common块，而

9、每个subroutine 有大量的参数传递有个软件的 subroutine 居然有 100 多个参数！。阅读这种代码简直让人崩溃！而最大的问题是，由于程序最初的设计没有任何软件工程的考虑，要继续开发和改良 这种没有封装和可扩展性的代码将会变得异常困难。举一个例子 3 。开发相对论量子化 学软件 DIRAC 时涉及到了一个四元矩阵，这种四元矩阵有两种存储方式： AN, N, 4 和A(4, N, N) 。由于某些历史原因，最初的设计采用了 A(N, N, 4) 。现在，由于内存硬件的 改变， A(N, N, 4) 的乘法操作比 A(4, N, N) 要慢 4 倍。但是，由于最初设计的缺陷，几 乎

10、所有的 subroutine 都是显式的处理 A 的各个下标，因此，假设要改良 A 的存储方式几乎 要对所有的代码进行大手术，这简直就是不可能的任务。因此，直到现在(2021)，DIRAC 还在忍受着这种四倍的性能惩罚！这是不重视软件工程的一个惨痛教训。由于学术领域的特性，一个组常常是“铁打的营盘流水的兵，一个学生参与软件开 发往往最多四五年就会离开，新来的学生要从头学起。由于学生根本不具有软件工程的背景， 而写代码水平又参差不齐，导致不同时期参加程序的代码，不管风格还是性能都相差甚远， 这种差异更使得软件的开展走向死胡同。Fortran 的结构化特性是把双刃剑。它使得程序开发的入门变得非常容

11、易，但又使长 期维护变得异常困难。特别是代码到达万行级别以上时候，后续开发者的工作量越来越大。 此时，软件开发者逐渐开始反思过去的教训。新的概念：封装，多态，面向对象开始走入 他们的视野。4 后起之秀： C+C+ 作为一种混血语言，兼具面向过程和面向对象的特性，很快稳坐了大型商业软件 开发语言的霸主地位。但是，不知为什么，理论化学界的会Fortran的人往往对C+有一种说不清楚的“敌视的态度。也许是一种情节吧，毕竟用 Fortran 人们开发了很多经典 的程序，就像 Visual C+出现之初，很多人还在恋恋不舍的使用着Turbo C+，因为Turbo C+ 开发了无数经典的软件。在 90 年

12、代末，一些理论化学研究组终于决定放弃 Fortran ，这个决定应该来说是很 需要勇气的，因为意味着放弃前人珍贵的 Fortran 程序库。 Frank Neese 在开发 ORCA (一个量子化学程序)时毅然决定使用C+，因为他认为保持代码的结构性和统一性与程序运行的性能是同等重要的。十几年过去了，ORCA的代码已达百万行，他发现 C+为保持代码的可维护性做出了重要的奉献。每一个新进入组的学生在一到两周内就可以对程序作 出实质性的奉献。他提到，新进入组的某些人确实对C+和C抱有极大的敌意，但是经过一段时间后，他们都同意“ It is much more convenient to use t

13、he ORCA C+ infrastructure compared to the Fortran codes they were used to.4不过，他也说， Fortran 也可以做到这一点。但是， Fortran 的面向对象特性是在 Fortran90 后才参加的(如 module ，但有人认为这简直是个“ ugly hack )，而历史 上大多数量子化学程序都是 Fortran77 的，设计本身又没考虑软件工程这一点，因此 Fortran 的面向对象特性很少直接的投入应用。90 年代中期，分子动力学软件NAMD开始开发。其设计者也决定采用C+。开发者之一 An drew Dalke

14、称，他们选择C+的原因是为了处理复杂的空间分解数据结构和进程间 通信5。NAMD是目前为止软件工程做的最好的科学软件之一。直到现在，NAMD还在维护和开发中，其性能和可扩展性在同类软件中都是一流的。Gaussian 是用 Fortran77 编写的，而 90 年代中期，从 Gaussian 公司中跑出来的一 批人Pople和Head-Gordan在编写Q-Chem时，也采用了 C+5 大论战：Fortran 和C+孰优孰劣好吧，终于还是到了这个让人头痛的问题。首先，我们还是看看性能吧。一些软件工程专业人士说，代码的“可维护性远比“性能更重要。作者认为，在 科学计算领域，这个说法是不适宜的，至少

15、换成“代码的可读性与性能同等重要，因为 这些软件，一旦运行起来常常都是以天为单位，其存储读取和浮点数操作及其巨大，一个 小小的性能提升可以使运行时间缩短几天，这对提高科研效率是及其重要的。因此，这里 将性能的考虑放在第一位。大家都比拟公认， Fortran 和 C 在性能上没有实质差异，因为他们的相对底层性，每 一条语句都可以比拟直接的翻译成对应的机器语言。因此决定性能的因素几乎只有算法。 而C+那么不同，C+为了实现多态等特性，添加了大量额外代码，这些性质可能会对性能造 成损害。最为人诟病的，就是虚函数和大型对象的复制。例如，某软件涉及到大量频繁的 I/O操作例如量子化学中分子积分的缓存文件

16、，测试发现，使用C+标准库iostream的 cout 对象类要比 C 的 fprintf 函数和 Fortran 的 write 语句要慢三倍左右。也有人认为，这些所谓的“性能杀手的责任不在语言，而在程序员。例如，大循环 体内的虚函数会大大降低程序的性能，而这完全可以通过重新设计类的层次结构或使用内 联函数来解决事实上有人认为在理论化学程序的设计中虚函数根本就没有必要使用； 大型对象的复制可以通过预取缓存的技术来解决，或者干脆防止这种操作。当然，这有偷 换概念之嫌。除此之外，一般认为对于同样的算法，Fortran , C , C+啲性能没有实质性的差异。数值计算的经典名著 Numerical

17、 Recipe ，在第一版时，里面的程序都是用 Fortran 也有 Lisp ， Pascal 之类 写的，而 2021 年第三版时，所有的程序都改成了 C+,里面也用了模板，继承等技术，可见他们也认为C+和 Fortran 的性能不会有明显差异。但是，还有一个不可忽略的因素，就是编译器！像C+这样的群众语言，新技术厂商会为其投入巨资进行研究,而 Fortran 这种现在小众的语言,他们的开发受到冷落。一旦编译器的质量下降，这种语言的性能和应用也会遭到致命的打击。一个分子模拟软件MODELLERS用Fortran95写的，在编译软件时，无论是 intel 还是GNU Fortran编译器 都

18、会产生各种各样的错误，开发人员不得不禁用一些优化选项来防止这些错误6 。另一个表达是，直到现在 2021，几乎没有哪个厂商生产了完全支持 Fortran2021 标准的编 译器！如果这样下去， Fortran 在性能上的优势也可能逐渐消失。下面我们看看软件工程上的考虑。Vincent Leroux 称，他确实发现“ maintaining large Fortran projects may turn into a nightmare easily,C+在清晰的表达抽象数据关系上有明显的优势。他以分子动力学软件 CHARM和NAMD为例，前者是Fortran 写的，后者是 C+写的，这两者代

19、码的清晰程度几乎有天地之别7。前面提到的ORCA也是一例。因此，人们倾向于认为 C+开发的程序更具有长远的生命力，更易扩展和维护。当然，用 Fortran 写出好的代码也并非不可能。一个例子是分子动力学软件 TINKER ， 另一个就是量子化学软件 GAMESS GAMESS已逾二十余年，它使用 Fortran77编写。由于 它的开发非常标准含有程序员手册；代码写作坚持统一风格；代码注释详细等，并具 有统一的DDI接口，因此GAMESS台终得到了量子化学界的广泛拥护。直到现在，很多新 的电子结构方法都借助 GAMESS勺平台来开展，女口 XMVB, XIAN CI , SAPT等等。但是， 这

20、两个似乎只是特例。大多数组里 Fortran 的程序人们之所以还在改良，似乎更多是出于 本钱的缘故。毕竟组里累计了多年的程序是舍不得扔的，而重写代码所需的工作量太巨大 了，或者说，根本不会做。这一点常被人忽略，但却很实在。比方，作者学校某个化学组 至今 2021还在使用一个用 QBASIC 写的磁性计算程序，这并不是因为他们对当初写这 段代码的师兄怀有感情，而是因为：现在组里根本没有人会写代码。6 迎合新技术？Fortran 在某些方面确实有些不思进取。从 77 到 95 标准整整经历了 19 年，指针、 动态内存分配、模块技术才姗姗来迟，而迄今类似于“析构函数的东西也不存在，从而 使垃圾回收

21、变得非常麻烦，这对大型程序的开发十分不利。而C+不仅天然存在这些特性，其丰富的 STL 可以很容易的构造高层次的数据结构堆栈，链表等。在这一方面， Fortran 是应当受到批评的。尽管并行技术，如 OpenMP, MPI等同时支持 Fortran 和C so C+，但是这些技 术都是在90年代出现的。事实上，对于大型程序的并行很多人还是提倡使用C+。C+的抽象技术可以减少节点通信模块与纯粹数值计算模块之间的耦合，而Fortran 很难做到这一点。就连以Fortran77为标准的GAMESS勺数据接口程序 DDI也是用C写的。前面提到， NAMD的作者也是这么认为的。2021 年左右开始流行的CUDA加速技术大大提高了理论化学的计算效率，它只支持Fortran 的CUDA技术还有些问题(Porland Group Fortran)，不知何年才能见到正式版本。Terachem作为第一个支持 GPU加速的量子化学软件，就是使用C编写的。如果Fo