科學計算編程中的Fortran

1、科學計算編程中的 Fortran科學計算編程中的 Fortran 與C+之爭自從有了程序設計語言，“哪種編程語言好就成為了亙古不變的話題。這個問題一 經提出，必然會招來一場巨大的口水仗。作者曾經在某些論壇上提出了類似“ Fortran 和 C+那個用的多之類的問題，回帖全部達幾十個以上，各種意見針鋒相對，猶如Fortran和C+信徒之間的“圣戰(zhàn)"一般好看。有很多人曾經請 C+語言之父Bjarne Stroustrup 做一個C+與其它編程語言的比擬, 而 Stroustrup 明確的拒絕了。他指出，從技術上講，一個所謂的“公平的比擬將會涉 及到大量的技術，這是一個工作量巨大的任務，絕

2、對不是簡單的用C+和其它語言寫同一段代碼然后比擬其運行時間就能完成的。這種比擬涉及到具體的應用領域和用戶需求，所 處理的信息類型，編譯器的質量不同語言的編譯器開發(fā)的投入是有相當大差異的，程 序員的水平與“偏好，編程語言的標準如究竟是C+97與Fortran90比擬，還是應該C+0x與Fortran2021 比擬？等等。他甚至認為，這種比擬是“ rarely meaningful "的1 。因此，今天作者也不打算為某種編程語言搖旗吶喊，而是僅就科學計算編程領域，特 別是，限于作者專業(yè)即量子化學和分子模擬，來談一談兩大“主流編程語言：Fortran和C+的在理論化學界的應用歷史，以及某些

3、人包括作者對它們的看法。1 Fortran 的美好時代毋庸置疑， 1957 年出現(xiàn)的 Fortran 是世界上第一個高級編程語言。它的出現(xiàn)，大大 降低了普通科研人員學習編程的門檻，而且增強了代碼的可移植性。在此之前，人們都是 用機器語言直接書寫程序，這種語言對于一般人而言難度太大了，而且是與運行機器相關， 因此很難寫出高效且具有可移植性的程序。例如， Roothaan 在研究原子自洽場的計算時專門為 IBM 7030 數(shù)字計算機寫了一些程 序，這些程序用來優(yōu)化 Slater 基組已經 10多年了。不幸的是，由于該程序是完全使用 IBM 的機器語言所書寫，因此在 20世紀 60年代，當這種機器逐

4、漸消失時，這些程序逐漸 成為了廢品。意識到這個資源的重要性， Clementi 及其同事決定把這些程序用 Fortran 全部重寫，并且增加了處理 Gauss 基組的功能 2 。這段代碼從此復活，成為了量子化學 程序庫中一個重要局部。Fortran 語言的重要性從此被理論化學家所知。它的優(yōu)點幾乎數(shù)不勝數(shù)。首先，它的 語法簡單，任何一個理論化學的研究生幾乎一天就能學會，可以迅速用它開展工作；其次， 它的運行效率極高，不要說現(xiàn)代編譯器如 GNU Fortran 或 intel Fortran 編譯器，就 是世界上第一個 Fortran 編譯器都可以將其每一語句都翻譯成幾乎沒有冗余的、效率至少 不低

5、于手寫的機器碼；第三， Fortran 代碼具有可移植性，與機器無關。很快，在 20世 紀7080年代，一批批量子化學程序如雨后春筍般出現(xiàn)，如早期的Gaussian ,Polyatom，以及后來的GAMESS NWChen等等，幾乎全部都是由 Fortran77編寫的。Fortran77 在量子化學領域絕對是功不可沒，它為普及和開展量子化學做出了巨大的奉獻。 那個時代， Fortran77 是很多自然科學研究生的必修課。自此， Fortran 成為了數(shù)值計算領域的“主流語言。2 C 語言的崛起20 實際 70年代， C 語言逐漸崛起。這個語言是為了編寫 Unix 操作系統(tǒng)而開發(fā)的。 很快，這種

6、“半匯編性質的高級語言，由于其具有極其靈活的控制機器的能力而深受計 算機專業(yè)人士的喜愛。不過，由于其學習難度較之 Fortran 稍高，而量子化學以純粹數(shù)值 計算為主， Fortran 足以滿足要求，因此 C 在量子化學領域沒有什么明顯優(yōu)勢，因此大多 數(shù)量子化學家對其不感興趣。此時， C 和 Fortran 處于“井水不犯河水的狀態(tài)。而 80 年代左右，分子模擬科學開始開展。由于分子模擬的流程相對復雜，F(xiàn)ortran77語言在實現(xiàn)某些功能時稍顯繁瑣，如對某些配置文件進行語法分析，一些模式識別和人工 智能過程等等，此時 C 語言的優(yōu)勢開始顯露，大量分子模擬領域的研究組開始用 C 開發(fā) 程序，如分

7、子對接軟件 Autodock 等等。 Fortran 壟斷地位的打破，說明理論化學領域編 程語言之戰(zhàn)的種子已經悄然的埋下。3 理論化學軟件開發(fā)的瓶頸在任何軟件開發(fā)領域學術界還是商業(yè)界，前人留下的代碼庫都是無比珍貴的財富。 因為無論程序員的水平有多高，代碼畢竟是一個字一個字的敲進去的。比方矩陣乘法這種 通用的操作都需要每次重新寫，那會浪費大量珍貴的人力財力。在前人的根底上開發(fā)新的 功能，是大型軟件開發(fā)的通用規(guī)那么。量子化學自 60 年代以來，積累了大量的 Fortran 程 序庫，它們的開發(fā)都是非常艱苦的，是無數(shù)量子化學家智慧的結晶，每個研究組都要在前 人的根底上繼續(xù)的研究，例如現(xiàn)在的 Gaus

8、sian09 里面還使用著當年 Pople 親手敲進去的 代碼。不幸的是，到了 90 年代，這種長期的積累，既是這個組的財富，同時卻也是軟件繼 續(xù)開展的一個致命的阻礙。這些開發(fā)于 60 年代的量子化學程序，幾乎都是“無組織無紀 律的開發(fā)的，根本沒有料到后來的開展程度。因此，很多組逐年積累達萬行的程序，幾 乎毫無任何代碼美感可言：變量命名難以理解我見過一個 Ewald 求和程序里面充滿著 p ， pp ， ppp 這樣的變量名，邏輯結構雜亂無章 goto ， if 之類隨意嵌套。維護 人員在閱讀以前的源碼時需要消耗大量的精力，而這是一個痛苦的過程。早期的量子化學 程序都有大量的common塊，而

9、每個subroutine 有大量的參數(shù)傳遞有個軟件的 subroutine 居然有 100 多個參數(shù)！。閱讀這種代碼簡直讓人崩潰！而最大的問題是，由于程序最初的設計沒有任何軟件工程的考慮，要繼續(xù)開發(fā)和改良 這種沒有封裝和可擴展性的代碼將會變得異常困難。舉一個例子 3 。開發(fā)相對論量子化 學軟件 DIRAC 時涉及到了一個四元矩陣，這種四元矩陣有兩種存儲方式： AN, N, 4 和A(4, N, N) 。由于某些歷史原因，最初的設計采用了 A(N, N, 4) ?，F(xiàn)在，由于內存硬件的 改變， A(N, N, 4) 的乘法操作比 A(4, N, N) 要慢 4 倍。但是，由于最初設計的缺陷，幾 乎

10、所有的 subroutine 都是顯式的處理 A 的各個下標，因此，假設要改良 A 的存儲方式幾乎 要對所有的代碼進行大手術，這簡直就是不可能的任務。因此，直到現(xiàn)在(2021)，DIRAC 還在忍受著這種四倍的性能懲罰！這是不重視軟件工程的一個慘痛教訓。由于學術領域的特性，一個組常常是“鐵打的營盤流水的兵，一個學生參與軟件開 發(fā)往往最多四五年就會離開，新來的學生要從頭學起。由于學生根本不具有軟件工程的背景， 而寫代碼水平又參差不齊，導致不同時期參加程序的代碼，不管風格還是性能都相差甚遠， 這種差異更使得軟件的開展走向死胡同。Fortran 的結構化特性是把雙刃劍。它使得程序開發(fā)的入門變得非常容

11、易，但又使長 期維護變得異常困難。特別是代碼到達萬行級別以上時候，后續(xù)開發(fā)者的工作量越來越大。 此時，軟件開發(fā)者逐漸開始反思過去的教訓。新的概念：封裝，多態(tài)，面向對象開始走入 他們的視野。4 后起之秀： C+C+ 作為一種混血語言，兼具面向過程和面向對象的特性，很快穩(wěn)坐了大型商業(yè)軟件 開發(fā)語言的霸主地位。但是，不知為什么，理論化學界的會Fortran的人往往對C+有一種說不清楚的“敵視的態(tài)度。也許是一種情節(jié)吧，畢竟用 Fortran 人們開發(fā)了很多經典 的程序，就像 Visual C+出現(xiàn)之初，很多人還在戀戀不舍的使用著Turbo C+，因為Turbo C+ 開發(fā)了無數(shù)經典的軟件。在 90 年

12、代末，一些理論化學研究組終于決定放棄 Fortran ，這個決定應該來說是很 需要勇氣的，因為意味著放棄前人珍貴的 Fortran 程序庫。 Frank Neese 在開發(fā) ORCA (一個量子化學程序)時毅然決定使用C+，因為他認為保持代碼的結構性和統(tǒng)一性與程序運行的性能是同等重要的。十幾年過去了，ORCA的代碼已達百萬行，他發(fā)現(xiàn) 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 )，而歷史 上大多數(shù)量子化學程序都是 Fortran77 的，設計本身又沒考慮軟件工程這一點，因此 Fortran 的面向對象特性很少直接的投入應用。90 年代中期，分子動力學軟件NAMD開始開發(fā)。其設計者也決定采用C+。開發(fā)者之一 An drew Dalke

14、稱，他們選擇C+的原因是為了處理復雜的空間分解數(shù)據結構和進程間 通信5。NAMD是目前為止軟件工程做的最好的科學軟件之一。直到現(xiàn)在，NAMD還在維護和開發(fā)中，其性能和可擴展性在同類軟件中都是一流的。Gaussian 是用 Fortran77 編寫的，而 90 年代中期，從 Gaussian 公司中跑出來的一 批人Pople和Head-Gordan在編寫Q-Chem時，也采用了 C+5 大論戰(zhàn)：Fortran 和C+孰優(yōu)孰劣好吧，終于還是到了這個讓人頭痛的問題。首先，我們還是看看性能吧。一些軟件工程專業(yè)人士說，代碼的“可維護性遠比“性能更重要。作者認為，在 科學計算領域，這個說法是不適宜的，至少

15、換成“代碼的可讀性與性能同等重要，因為 這些軟件，一旦運行起來常常都是以天為單位，其存儲讀取和浮點數(shù)操作及其巨大，一個 小小的性能提升可以使運行時間縮短幾天，這對提高科研效率是及其重要的。因此，這里 將性能的考慮放在第一位。大家都比擬公認， Fortran 和 C 在性能上沒有實質差異，因為他們的相對底層性，每 一條語句都可以比擬直接的翻譯成對應的機器語言。因此決定性能的因素幾乎只有算法。 而C+那么不同，C+為了實現(xiàn)多態(tài)等特性，添加了大量額外代碼，這些性質可能會對性能造 成損害。最為人詬病的，就是虛函數(shù)和大型對象的復制。例如，某軟件涉及到大量頻繁的 I/O操作例如量子化學中分子積分的緩存文件

16、，測試發(fā)現(xiàn)，使用C+標準庫iostream的 cout 對象類要比 C 的 fprintf 函數(shù)和 Fortran 的 write 語句要慢三倍左右。也有人認為，這些所謂的“性能殺手的責任不在語言，而在程序員。例如，大循環(huán) 體內的虛函數(shù)會大大降低程序的性能，而這完全可以通過重新設計類的層次結構或使用內 聯(lián)函數(shù)來解決事實上有人認為在理論化學程序的設計中虛函數(shù)根本就沒有必要使用； 大型對象的復制可以通過預取緩存的技術來解決，或者干脆防止這種操作。當然，這有偷 換概念之嫌。除此之外，一般認為對于同樣的算法，F(xiàn)ortran , C , C+啲性能沒有實質性的差異。數(shù)值計算的經典名著 Numerical

17、 Recipe ，在第一版時，里面的程序都是用 Fortran 也有 Lisp ， Pascal 之類 寫的，而 2021 年第三版時，所有的程序都改成了 C+,里面也用了模板，繼承等技術，可見他們也認為C+和 Fortran 的性能不會有明顯差異。但是，還有一個不可忽略的因素，就是編譯器！像C+這樣的群眾語言，新技術廠商會為其投入巨資進行研究,而 Fortran 這種現(xiàn)在小眾的語言,他們的開發(fā)受到冷落。一旦編譯器的質量下降，這種語言的性能和應用也會遭到致命的打擊。一個分子模擬軟件MODELLERS用Fortran95寫的，在編譯軟件時，無論是 intel 還是GNU Fortran編譯器 都

18、會產生各種各樣的錯誤，開發(fā)人員不得不禁用一些優(yōu)化選項來防止這些錯誤6 。另一個表達是，直到現(xiàn)在 2021，幾乎沒有哪個廠商生產了完全支持 Fortran2021 標準的編 譯器！如果這樣下去， Fortran 在性能上的優(yōu)勢也可能逐漸消失。下面我們看看軟件工程上的考慮。Vincent Leroux 稱，他確實發(fā)現(xiàn)“ maintaining large Fortran projects may turn into a nightmare easily,C+在清晰的表達抽象數(shù)據關系上有明顯的優(yōu)勢。他以分子動力學軟件 CHARM和NAMD為例，前者是Fortran 寫的，后者是 C+寫的，這兩者代

19、碼的清晰程度幾乎有天地之別7。前面提到的ORCA也是一例。因此，人們傾向于認為 C+開發(fā)的程序更具有長遠的生命力，更易擴展和維護。當然，用 Fortran 寫出好的代碼也并非不可能。一個例子是分子動力學軟件 TINKER ， 另一個就是量子化學軟件 GAMESS GAMESS已逾二十余年，它使用 Fortran77編寫。由于 它的開發(fā)非常標準含有程序員手冊；代碼寫作堅持統(tǒng)一風格；代碼注釋詳細等，并具 有統(tǒng)一的DDI接口，因此GAMESS臺終得到了量子化學界的廣泛擁護。直到現(xiàn)在，很多新 的電子結構方法都借助 GAMESS勺平臺來開展，女口 XMVB, XIAN CI , SAPT等等。但是， 這

20、兩個似乎只是特例。大多數(shù)組里 Fortran 的程序人們之所以還在改良，似乎更多是出于 本錢的緣故。畢竟組里累計了多年的程序是舍不得扔的，而重寫代碼所需的工作量太巨大 了，或者說，根本不會做。這一點常被人忽略，但卻很實在。比方，作者學校某個化學組 至今 2021還在使用一個用 QBASIC 寫的磁性計算程序，這并不是因為他們對當初寫這 段代碼的師兄懷有感情，而是因為：現(xiàn)在組里根本沒有人會寫代碼。6 迎合新技術？Fortran 在某些方面確實有些不思進取。從 77 到 95 標準整整經歷了 19 年，指針、 動態(tài)內存分配、模塊技術才姍姍來遲，而迄今類似于“析構函數(shù)的東西也不存在，從而 使垃圾回收

21、變得非常麻煩，這對大型程序的開發(fā)十分不利。而C+不僅天然存在這些特性，其豐富的 STL 可以很容易的構造高層次的數(shù)據結構堆棧，鏈表等。在這一方面， Fortran 是應當受到批評的。盡管并行技術，如 OpenMP, MPI等同時支持 Fortran 和C so C+，但是這些技 術都是在90年代出現(xiàn)的。事實上，對于大型程序的并行很多人還是提倡使用C+。C+的抽象技術可以減少節(jié)點通信模塊與純粹數(shù)值計算模塊之間的耦合，而Fortran 很難做到這一點。就連以Fortran77為標準的GAMESS勺數(shù)據接口程序 DDI也是用C寫的。前面提到， NAMD的作者也是這么認為的。2021 年左右開始流行的CUDA加速技術大大提高了理論化學的計算效率，它只支持Fortran 的CUDA技術還有些問題(Porland Group Fortran)，不知何年才能見到正式版本。Terachem作為第一個支持 GPU加速的量子化學軟件，就是使用C編寫的。如果Fo