科学计算编程中的Fortran

科学计算编程中的Fortran与C++之争自从有了程序设计语言，“哪种编程语言好”就成为了亘古不变的话题。这个问题一经提出，必然会招来一场巨大的口水仗。作者曾经在某些论坛上提出了类似“Fortran和C++那个用的多”之类的问题，回帖全部达几十个以上，各种意见针锋相对，犹如Fortran和C++信徒之间的“圣战”一般好看。有很多人曾经请C++语言之父BjarneStroustrup做一个C++与其它编程语言的比较，而Stroustrup明确的拒绝了。他指出，从技术上讲，一个所谓的“公平”的比较将会涉及到大量的技术，这是一个工作量巨大的任务，绝对不是简单的用C++和其它语言写同一段代码然后比较其运行时间就能完成的。这种比较涉及到具体的应用领域和用户需求，所处理的信息类型，编译器的质量（不同语言的编译器开发的投入是有相当大差别的），程序员的水平与“偏好”，编程语言的标准（如究竟是C++97与Fortran90比较，还是应该C++0x与Fortran2003比较？）等等。他甚至认为，这种比较是“rarelymeaningful”的[1]。因此，今天作者也不打算为某种编程语言摇旗呐喊，而是仅就科学计算编程领域，特别是，限于作者专业即量子化学和分子模拟，来谈一谈两大“主流”编程语言：Fortran和C++的在理论化学界的应用历史，以及某些人（包括作者）对它们的看法。1Fortran的美好时代毋庸置疑，1957年出现的Fortran是世界上第一个高级编程语言。它的出现，大大降低了普通科研人员学习编程的门槛，而且增强了代码的可移植性。在此之前，人们都是用机器语言直接书写程序，这种语言对于一般人而言难度太大了，而且是与运行机器相关，因此很难写出高效且具有可移植性的程序。例如，Roothaan在研究原子自洽场的计算时专门为IBM7030数字计算机写了一些程序，这些程序用来优化Slater基组已经10多年了。不幸的是，由于该程序是完全使用IBM的机器语言所书写，因此在20世纪60年代，当这种机器逐渐消失时，这些程序逐渐成为了废品。意识到这个资源的重要性，Clementi及其同事决定把这些程序用Fortran全部重写，并且增加了处理Gauss基组的功能[2]。这段代码从此复活，成为了量子化学程序库中一个重要部分。Fortran语言的重要性从此被理论化学家所知。它的优点几乎数不胜数。首先，它的语法简单，任何一个理论化学的研究生几乎一天就能学会，可以迅速用它开展工作；其次，它的运行效率极高，不要说现代编译器（如GNUFortran或intelFortran编译器），就是世界上第一个Fortran编译器都可以将其每一语句都翻译成几乎没有冗余的、效率至少不低于手写的机器码；第三，Fortran代码具有可移植性，与机器无关。很快，在20世纪70～80年代，一批批量子化学程序如雨后春笋般出现，如早期的Gaussian，Polyatom，以及后来的GAMESS，NWChem等等，几乎全部都是由Fortran77编写的。Fortran77在量子化学领域绝对是功不可没，它为普及和发展量子化学做出了巨大的贡献。那个时代，Fortran77是很多自然科学研究生的必修课。自此，Fortran成为了数值计算领域的“主流”语言。2C语言的崛起20实际70年代，C语言逐渐崛起。这个语言是为了编写Unix操作系统而开发的。很快，这种“半汇编”性质的高级语言，由于其具有极其灵活的控制机器的能力而深受计算机专业人士的喜爱。不过，由于其学习难度较之Fortran稍高，而量子化学以纯粹数值计算为主，Fortran足以满足要求，因此C在量子化学领域没有什么明显优势，因此大多数量子化学家对其不感兴趣。此时，C和Fortran处于“井水不犯河水”的状态。而80年代左右，分子模拟科学开始发展。由于分子模拟的流程相对复杂，Fortran77语言在实现某些功能时稍显繁琐，如对某些配置文件进行语法分析，一些模式识别和人工智能过程等等，此时C语言的优势开始显露，大量分子模拟领域的研究组开始用C开发程序，如分子对接软件Autodock等等。Fortran垄断地位的打破，表明理论化学领域编程语言之战的种子已经悄然的埋下。3理论化学软件开发的瓶颈在任何软件开发领域（学术界还是商业界），前人留下的代码库都是无比宝贵的财富。因为无论程序员的水平有多高，代码毕竟是一个字一个字的敲进去的。比如矩阵乘法这种通用的操作都需要每次重新写，那会浪费大量宝贵的人力财力。在前人的基础上开发新的功能，是大型软件开发的通用规则。量子化学自60年代以来，积累了大量的Fortran程序库，它们的开发都是非常艰苦的，是无数量子化学家智慧的结晶，每个研究组都要在前人的基础上继续的研究，例如现在的Gaussian09里面还使用着当年Pople亲手敲进去的代码。不幸的是，到了90年代，这种长期的积累，既是这个组的财富，同时却也是软件继续发展的一个致命的阻碍。这些开发于60年代的量子化学程序，几乎都是“无组织无纪律”的开发的，根本没有料到后来的发展程度。因此，很多组逐年积累达万行的程序，几乎毫无任何代码美感可言：变量命名难以理解（我见过一个Ewald求和程序里面充斥着p，pp，ppp这样的变量名），逻辑结构杂乱无章（goto，if之类随意嵌套）。维护人员在阅读以前的源码时需要消耗大量的精力，而这是一个痛苦的过程。早期的量子化学程序都有大量的common块，而每个subroutine有大量的参数传递（有个软件的subroutine居然有100多个参数！！）。阅读这种代码简直让人崩溃！而最大的问题是，由于程序最初的设计没有任何软件工程的考虑，要继续开发和改进这种没有封装和可扩展性的代码将会变得异常困难。举一个例子[3]。开发相对论量子化学软件DIRAC时涉及到了一个四元矩阵，这种四元矩阵有两种存储方式：A(N,N,4)和A(4,N,N)。由于某些历史原因，最初的设计采用了A(N,N,4)。现在，由于内存硬件的改变，A(N,N,4)的乘法操作比A(4,N,N)要慢4倍。但是，由于最初设计的缺陷，几乎所有的subroutine都是显式的处理A的各个下标，因此，若要改进A的存储方式几乎要对所有的代码进行大手术，这简直就是不可能的任务。因此，直到现在（2011），DIRAC还在忍受着这种四倍的性能惩罚！这是不重视软件工程的一个惨痛教训。由于学术领域的特性，一个组常常是“铁打的营盘流水的兵”，一个学生参与软件开发往往最多四五年就会离开，新来的学生要从头学起。由于学生基本不具有软件工程的背景，而写代码水平又参差不齐，导致不同时期加入程序的代码，不论风格还是性能都相差甚远，这种差异更使得软件的发展走向死胡同。Fortran的结构化特性是把双刃剑。它使得程序开发的入门变得非常容易，但又使长期维护变得异常困难。特别是代码达到万行级别以上时候，后续开发者的工作量越来越大。此时，软件开发者逐渐开始反思过去的教训。新的概念：封装，多态，面向对象开始走入他们的视野。4后起之秀：C++C++作为一种混血语言，兼具面向过程和面向对象的特性，很快稳坐了大型商业软件开发语言的霸主地位。但是，不知为什么，理论化学界的会Fortran的人往往对C++有一种说不清楚的“敌视”的态度。也许是一种情节吧，毕竟用Fortran人们开发了很多经典的程序，就像VisualC++出现之初，很多人还在恋恋不舍的使用着TurboC++，因为TurboC++开发了无数经典的软件。在90年代末，一些理论化学研究组终于决定放弃Fortran，这个决定应该来说是很需要勇气的，因为意味着放弃前人宝贵的Fortran程序库。FrankNeese在开发ORCA（一个量子化学程序）时毅然决定使用C++，因为他认为保持代码的结构性和统一性与程序运行的性能是同等重要的。十几年过去了，ORCA的代码已达百万行，他发现C++为保持代码的可维护性做出了重要的贡献。每一个新进入组的学生在一到两周内就可以对程序作出实质性的贡献。他提到，新进入组的某些人确实对C++和C抱有极大的敌意，但是经过一段时间后，他们都同意“ItismuchmoreconvenienttousetheORCAC++infrastructurecomparedtotheFortrancodestheywereusedto.”[4]不过，他也说，Fortran也可以做到这一点。但是，Fortran的面向对象特性是在Fortran90后才加入的（如module，但有人认为这简直是个“uglyhack”），而历史上大多数量子化学程序都是Fortran77的，设计本身又没考虑软件工程这一点，因此Fortran的面向对象特性很少直接的投入应用。90年代中期，分子动力学软件NAMD开始开发。其设计者也决定采用C++。开发者之一AndrewDalke称，他们选择C++的原因是为了处理复杂的空间分解数据结构和进程间通信[5]。NAMD是目前为止软件工程做的最好的科学软件之一。直到现在，NAMD还在维护和开发中，其性能和可扩展性在同类软件中都是一流的。Gaussian是用Fortran77编写的，而90年代中期，从Gaussian公司中跑出来的一批人(Pople和Head-Gordan)在编写Q-Chem时，也采用了C++……5大论战：Fortran和C++孰优孰劣好吧，终于还是到了这个让人头痛的问题。首先，我们还是看看性能吧。一些软件工程专业人士说，代码的“可维护性”远比“性能”更重要。作者认为，在科学计算领域，这个说法是不合适的，至少换成“代码的可读性与性能同等重要”，因为这些软件，一旦运行起来常常都是以天为单位，其存储读取和浮点数操作及其巨大，一个小小的性能提升可以使运行时间缩短几天，这对提高科研效率是及其重要的。因此，这里将性能的考虑放在第一位。大家都比较公认，Fortran和C在性能上没有实质差别，因为他们的相对底层性，每一条语句都可以比较直接的翻译成对应的机器语言。因此决定性能的因素几乎只有算法。而C++则不同，C++为了实现多态等特性，添加了大量额外代码，这些性质可能会对性能造成损害。最为人诟病的，就是虚函数和大型对象的复制。例如，某软件涉及到大量频繁的I/O操作（例如量子化学中分子积分的缓存文件），测试发现，使用C++标准库iostream的cout对象类要比C的fprintf函数和Fortran的write语句要慢三倍左右。也有人认为，这些所谓的“性能杀手”的责任不在语言，而在程序员。例如，大循环体内的虚函数会大大降低程序的性能，而这完全可以通过重新设计类的层次结构或使用内联函数来解决（事实上有人认为在理论化学程序的设计中虚函数根本就没有必要使用）；大型对象的复制可以通过预取缓存的技术来解决，或者干脆避免这种操作。当然，这有偷换概念之嫌。除此之外，一般认为对于同样的算法，Fortran，C，C++的性能没有实质性的差异。数值计算的经典名著NumericalRecipe，在第一版时，里面的程序都是用Fortran(也有Lisp，Pascal之类)写的，而2007年第三版时，所有的程序都改成了C++，里面也用了模板，继承等技术，可见他们也认为C++和Fortran的性能不会有明显差别。但是，还有一个不可忽略的因素，就是编译器！像C++这样的大众语言，新技术厂商会为其投入巨资进行研究，而Fortran这种现在小众的语言，他们的开发受到冷落。一旦编译器的质量下降，这种语言的性能和应用也会遭到致命的打击。一个分子模拟软件MODELLER是用Fortran95写的，在编译软件时，无论是intel还是GNUFortran编译器都会产生各种各样的错误，开发人员不得不禁用一些优化选项来避免这些错误[6]。另一个体现是，直到现在（2011），几乎没有哪个厂商生产了完全支持Fortran2003标准的编译器！如果这样下去，Fortran在性能上的优势也可能逐渐消失。下面我们看看软件工程上的考虑。VincentLeroux称，他确实发现“maintaininglarge