Windows、Linux下的Fortran编译器简介及推荐 v2.0
vitrol 2012-07-12
Windows、Linux下都有些什么常用的Fortran编译器？
在开始前，先得点明一个很基本的观念：编译器（Complier）不等于IDE（Integrated Development Environment，集成开发环境）。前者只提供编译Fortran代码的功能，后者提供了从代码编辑器、编译器、调试器和图形用户界面工具（百度百科）。一个很有趣的现象是，Windows下现成可用的都是IDE，Linux下的则都是Complier。但千万不要以为前者就该多么方便，后者就得多么麻烦，具体为什么我在后面会提到。
一、Windows
实际上，在Win平台中，大家用得最多的大概是基于微软Visual Studio因而集成了一整套IDE的、商业Fortran编辑器。这里只介绍两个：CVF，IVF。当然还有非商业的，基于命令行的编译器，如gfortran/g95等等，但我没尝试过，因为这样的话我更愿意直接到linux下工作呢。我个人非常期待关于Windows下命令行编译器的使用补充，如果是像本文一样的入门就更赞了～
1）Compad Visual Fortran
最常见的就是Compad Visual Fortran v6.5或v6.6，基于VS6。这是Win98时代的东东，更新到v6.6c就被Intel收购了，但到了2011年的今天，我对门实验室的童鞋们都依然在用。CVF我只以VS6试用过，不知道是否支持更高版本的VS，所以个人推荐还是用最小巧，最简单的VS6。
版本方面，网络上最常见的是v6.5的安装包+v6.6b或c的升级包。个人推荐不要升级到v6.6c，最多v6.6b就好。因为不知什么原因，我用到程序只明确支持到v6.6b，在6.6c编译不过。
操作系统方面，确认百分比支持的是WinXP及之前版本。Vista我没试过，听说是根本就不兼容；Win7是勉强支持的，但都有这样那样的小毛病，推荐安装微软自己出品的、Win7专业版以上才可用、免费的Virtual PC XP-Mode。这是微软为了解决兼容性问题，特意为Win7打造的微型XP虚拟机，活脱脱就是XP再生，当然可以兼容CVF在内的众多软件。
CVF只支持到Fortran 95标准，不支持任何03以上的特性，而且界面、功能远不如后继者IVF完善。但他的优点非常明显，因为用的人多，所以你向身边的人可能就在用，可以随时请教；你用到的程序，很可能就是一个现成的CVF Project；加上下载XX方便（CVF本身是免费的，而VS6一搜就有一大把的序列号），体积轻小、对配置要求极低，所以还是值得推荐的。
2）Intel Visual Fortran
这是CVF的后继者，也是我以前一直在用的编译器。目前正不断更新，最新版本是2011 XE，版本号是2011.0.084，或12.0.084。我的使用经历是IVF 11.1.69
最新的2011 XE支持扩展的Fortran2003标准，也就是吸纳了部分2008特性，而2003本身除了两个特性没实现外已经差不多完现了。
操作系统方面，Windows全系统支持。因为我没安装过，所以不确定具体能支持哪些VS版本，2010和2008应该是可以的，2005不清楚，但往下就肯定不支持了。
但可悲的是，v12系列刚发布没半年，价格高达700刀，想用都用不起。
盗版方面，安装程序和授权文件在网上很难找到，较常见的还是v11系列。但有一点要注意，v11对Win7支持是有缺陷的，只有11.1.48以上的版本才完整支持，大家下载时务必留意。Vista我压根没关注，所以不知道情形；XP就好办了，100%兼容。v11系列只支持VS2005和2008，2010不清楚，大家下载VS时也请留意。
3）其他
在Win下比较常见的还有PGI Fortran，更新发布比IVF要勤快，也容易下载到（VeryCD.com就有），听说口碑也不错，但我没用过，没发言权。Windows下面到底都有些什么编译器，有些什么差异，比较结果又是怎样，大家有兴趣可以去下面的网址看看：
（http://www.polyhedron.com/compare0html）
最后罗嗦一句，我自己最近一年有良心发现的倾向，越来越想去尊重他人的劳动成功，因而越来越抗拒盗版。更不想自己的研究工作根植于一些不道德的行为，如盗版。囊中羞涩之下，又加上对GNU project的认同，俺目前的工作环境都已经全面转向Linux及自由软件。所以，俺不会再关注Win下的商业软件了，最近的这些文章也算是作个告别吧～实际上，俺最近在学Emacs，所以也乐意多写点东西练练手。
二、Linux
之前提到过，Windows下面的Fortran发行版，多半是整合了IDE的商业版，价格不菲。而Linux下则是完全不同的氛围，常用的编译器清一色都是免费，甚至开源。缺点只是：没有集成统一的IDE，在可视化、在编辑调试方面似乎不那么方便。——但事情不是这样的。
Linux下有伟大的开源IDE，Eclipse可以替代VS；更有其他更自由更高效的解决方案，——只要你愿意花时间学习。
当然，爱怎么折腾都全凭个人喜好。实际上，我实验室里面的师兄们都是简简单单随便一个文本编辑器＋编译器就了解，纯手工维护。这里那么多方案，只是提供更多选择的可能性，让大家知道，离开Windows来到linux其实是一种解放。
我自己用的Linux发行版是32位的Ubuntu10.04，下面也主要以之为例。以下提到的所有软件，在不同发行版中照样可用，大家不必担心。
１）两种解决方案：IDE or DIY
先说IDE，大名鼎鼎的跨平台、自由、集成开发环境Eclipse就有专为Fortran设计的插件Photran，支持所有常见的Fortran编译器，如ifort、gfortran、g95等等。虽说一时间还比不上Windows下的VS，但已经相距不远了。（注，不是说强大的Eclipse比不上VS，而是身为插件的Photran还不够成熟，Photran+ifort还比不上IVF）。关于Eclipse和Photran可以自行Google之。下载也容易，Ubuntu的软件中心就有，虽然版本要旧一点，但胜在方便。
关于IDE，我一师弟提到了Code::Blocks下也有Fortran插件，dongyuanxun在回复中也说：“Fortran的IDE可以使用跨平台的Code::Blocks，代码完成，函数跳转都挺不错。”下面是百度百科的资料：
“Code::Blocks 是一个开放源码的全功能的跨平台C/C++集成开发环境. Code::Blocks是开放源码软件。Code::Blocks由纯粹的C++语言开发完成，它使用了蓍名的图形界面库wxWidgets(2.6.2 unicode)版。对于追求完美的C++程序员，再也不必忍受Eclipse的缓慢，再也不必忍受VS.NET的庞大和高昂的价格。”
（http://baike.baidu.com/view/1562377.htm）
我自己是装了Eclipse+Photran的，但一次都没用过，因为Linux下有更强大的方案。继承自Unix，Linux和Unix一样，都有一种软件开发的美学：一个软件负责一种功能，把一种功能开发到极致，然后让不同的最好的软件互相协作。开发Fortran程序也可以做得到，把IDE拆分为：编辑器 + 项目管理维护软件 + 编译器，我个人所推崇的方案是：GNU/Emacs + GNU Make + Complier（如ifort）
2）Code Editor
Emacs与Vim并称编辑器中的神器，Vim的美誉是“编辑器之神“，而Emacs的美誉则是“神的编辑器“，我个人更喜欢Emacs的自由及无限可定制性，其他朋友凭自己喜欢也可以选用Vim。唯一需要注意的是，这两件神器是需要花时间学，花更多时间去磨合的，虽然学会之后能大幅提高工作效率，但学习的过程是决计少不了。
Emacs自带Fortran-Mode和F90-Mode，对fixed和free两种fortran书写格式都提供语法高亮，为fortran程序的编写和调试提供了非常周到的环境。而且还有大量的插件可供下载，如语法检查及自动补全，与编译器的整合等等，只要愿意花心思，完全可以武装到牙齿。我目前正在学习中，最近的两篇文章就是用Emacs写就的。
关于Emacs的入门材料，网上有很多，但其实打开Emacs，按照她自带的中文Tutorial试一遍就知道个大概了。但要发挥Emacs的无比威力，得进一步深化学习；中文的实体书却不见售，我是在淘宝上买了本复印的《学习GNU Emacs 第二版》，这本书早就绝版，想买都买不到。
下载同样可以到Ubuntu的软件中心搜索，最新版是23.3，Ubuntu收录的是23.1，区别不大。
如果不想折腾，可以用自由桌面自带的文本编辑器，如Ubuntu上就自动有gedit，也支持语法高亮，一般人而言已经够用了。
3）GNU Make
关于make这个工具，三言两语很难说得清，大家可以参考wiki。
（http://zh.wikipedia.org/wiki/Make，更推荐英文版wiki）
在我理解中，make是一个很好的软件项目管理及维护的自动化工具，我们要进行的Fortran程序设计自然也在其中。她协助你将一系列繁琐的编译管理工作给一次性设计好，然后封装为单独的一个文本文件叫makefile，makefile文件描述代码文件之间的依赖关系，决定他们应该何时以什么编译器编译，如何协调不同的代码版本，等等等等。几乎所有的大型软件工程，都在用makefile来维护，任何一个IDE背后都有一个make。就如微软的VS，看似彻头彻尾的图形界面，独立的项目管理，其背后，实际也只是一个nmake程序 + makefile文件。所谓的Visual Studio，不过是把makefile文件里的语句给可视化了而已。
make的功能非常非常强大，对于小程序来说，make不是必需，但只要你代码上了一万行，分了模块、分了文件，那么，你就只能选择make，除非你想承受没完没了的手工维护之苦。大规模的程序开发��make来维护，——这在学术界、工业界已经是惯例了。我接触过宇宙学上著名的Fortran程序：CosmoMC，她就是用make来维护的。
make也有不少版本，我推荐的自然是linux下最常用的GNU make。不需安装，任何linux发行版必然自带，要学的只是该怎么写makefile文件。关于make的资料非常丰富，网上一搜就一大把；中文的教材方面，我用的是《GNU make项目管理 第三版》也是绝版书，在淘宝上有复印版可买到。
4）Complier
linux下的Fortran编译器很丰富，而且几乎都是免费的。下面网址中的都列举得差不多了。另外还有IBM公司的xlfortran，口碑非常好，似乎是第一个完整实现fortran2003标准的编译器，但可惜只支持基于IBM自己的powerpc，其他平台得用IBM公司提供的模拟器。
我自己用的是ifort，瀚海Fortran版上的朋友以及超算中心服务器上的用户也大多用ifort。我身边用得比较多的还有gfortran和g95，这两者都是开源的。尤其是gfortran，更是GNU Project里的成员。
g95虽然开源，但只是作者一人在维护，不是非常推荐。其他的编译器我没试过，没发言权，不敢妄自评论。
关于gfortran，因为我以前在实际使用中并不愉快，所以不敢多说。我在《 Ubuntu10.04_i386 下安装 ifort 11.1.072 》一文写到：“GNU Project 贡献了无数优秀的g字开头的软件、程序，如gcc，GNU/emacs等，但绝对不包括gfortran，比起ifort，gfortran的效率及容错性都不甚如意。”这是有失公允的。我更是没有在亲自试验的情况下，引用了科大论坛以前的某位朋友的观点：“gfortran和ifort编译出来程序的运行效率可以差个两三倍。“这就很不严谨了，在此真诚道歉。
提到编译器，不得不说一说对古老的Fortran77的支持。由于F77时代积累了无数珍贵代码，及Fortran标准的要求，所有编译器都是号称向下兼容的。但实际一用起来就未必是这么一回事了。这里有一个概念，叫对劣质代码的容错性。
以我实验室流传的程序为例，最初写的时候就不规范，用到了很多新标准所建议弃用的语法，以前用古老的f77、g77编译器倒没什么。后来一升级系统（由FC4升到ubuntu8.04），f77和g77都装不上了，只好用新版的编译器。我处于对GNU的无上推崇，首先选用的自然是gfortran，哪知一编译就一大堆警告和错误，仔细看看提示，发现要全部消除的话几乎得把程序重写！后来换了ifort，直接编译通过，运行良好。这本来只是我们的程序写得太烂，与编译器无关，但既然已成事实了，总得希望新版的编译器宽容一点不是？从此之后，我就一直用intel的编译器了……也说出了之前评价gfortran的那句话。
说到这，大家都知道我要推荐的是什么编译器了。关于ifort的下载、安装和设置请参考我之前那篇文章，这里就不多说了。
为了让大家对gfortran有个比较全面的理解，我想转贴“编程爱好者论坛“上dongyuanxun朋友的回复。我从他的回复里学到很多，在此深深感谢。
dongyuanxun:
不过lz的观点有些偏颇。
Windows下除了那些商业软件外，gfortran/g95也可以在windows下正常使用，这个不在话下。
我没用过g95，下面只说一下gfortran。Windows/Linux下gfortran（4.5以上版本，4.4之下的版本不做评述）的性能和ivf相比差距不大。但由于gfortran集成了gnu家族的参数复杂，所以很多初学者不太会用。
lz说的一编译就一大堆警告和错误，我猜想可能是和默认列长度有关，ivf默认支持很长，gfortran取消限制需要加入-ffree-line-length-0。当然还有其他的不同，在此不做赘述。我使用gfortran编译经典f77代码从来没出现什么问题。
而lz说的gfortran和ifort编译出来程序的运行效率可以差个两三倍，就没有道理了。我曾经比较过，gfortran在除了matmul函数和三角函数远慢于ivf外，其他运算速度要远远高于ivf。
而matmul和三角函数也有另外的处理方式。gfortran有个开关-fexternal-blas，这个可以把matmul函数解析到外部的blas库，如mkl的blas、比mkl还快的gotoblas、ATLAS，这样得到的目标代码速度要超过ivf的matmul的速度。对于三角函数，Linux下使用-mveclibabi=svml -lsvml -limf -lintlc 可以直接链接到mkl的svml库，或者使用-mveclibabi=acml -lacml_mv 链接到acml库，这样速度就和ivf相同了。Windows下比较麻烦，因为链接到intel的库要依赖vc的库，所以最好链接到svml的dll进行处理。另外的方法即是使用通用的SIMD技术，把三角函数重写（gcc），然后gfortran再去链接它。
另外考虑到开源跨平台计算库，比如fftw、gotoblas、atlas，这些东西用gcc/gfortran很好编译，用vc/intel编译器基本编译不出来，虽然可以通过动态连接库dll来使得intel使用，还不如直接使用gcc/gfortran来的便捷。
最后最重要的是免费开源，ivf在windows下收费，Linux下也只是对个人免费而已，商业开发需要授权。开源这个挺好的，编译器有时会不时的出现bug，intel的bug得报告后确认，还得等下个版本，还不一定修复，gfortran就不同了，可以去bugzilla上查阅bug，兴许就有解决的补丁，然后自己重新编译gfortran一下就行了。
默认编译呢，确实差距很大的，这是因为ivf不加参数是/O1优化，而且fastmath自动开启（有时会产生错误结果，发现不对劲时要手动关闭），而 gfortran默认好像是-O0不优化（反正没有ivf优化级别高），不开启fastmath，所以默认参数表面上产生gfortran远远不如ivf 的假象。在此，引用一个说法，某人说过，intel这样做是想推销他的编译器而已（默认开关就很快）。
5）其他
关于make，科大论坛上的IceAge朋友推荐了cmake，我挺感兴趣，于是查了下。有空的话就学一学：
“CMake是一个比make更高级的编译配置工具，它可以根据不同平台、不同的编译器，生成相应的Makefile或者vcproj项目。通过编写CMakeLists.txt，可以控制生成的Makefile，从而控制编译过程。CMake自动生成的Makefile不仅可以通过make命令构建项目生成目标文件，还支持安装（make install）、测试安装的程序是否能正确执行（make test，或者ctest）、生成当前平台的安装包（make package）、生成源码包（make package_source）、产生Dashboard显示数据并上传等高级功能，只要在CMakeLists.txt中简单配置，就可以完成很多复杂的功能，包括写测试用例。如果有嵌套目录，子目录下可以有自己的CMakeLists.txt。总之，CMake是一个非常强大的编译自动配置工具，支持各种平台，KDE也是用它编译的，感兴趣的可以试用一下。”
IceAge还提到了IDB，我没理解错的话，应该是Intel DeBugger，另外还有GNU DeBugger，GDB。我自己在调试工具方面的理解和实践很浅薄，所以在上面没有说。这里特意提到，是想借IceAge的方案来弥补。他的方案是： Vim + cmake + IDB + ifort， 有兴趣的朋友可以仔细调研。这里引以下关于GDB的讨论：
f2003：
对Fortran最大的两点遗憾是 gdb对Fortran支持不好……
dongyuanxun：
主要是动态数组gdb支持不好，所以要使用archergdb，但是archergdb不是紧跟gdb的trunk的，所以有些特性也发挥不出来，我曾经试图把archergdb的补丁分离合并到gdb里，编译未果，要改太多东西了。
补充一下，gcc/gfortran的调试是个硬伤，不如intel编译器的调试器好，所以对个人的调试水平比较高。虽然可以使用archergdb来代替gdb，显示还是没有ivf的好。
三、尾声
说了那么多，其实都只是一些皮毛性质的介绍。要学会fortran，只需也必须自己亲自花时间去钻研。而fortran语言也只是科研的一件工具，能用就行，科研本身才是最重要的，千万不要舍本逐末。我所写的这些，是根据我的情况、我的需求、我的经历来写的，仅供参考。如果我的这些文字能帮大家节省一些入门时间，那我就非常满足了。我这些文字，贻笑大方本不算什么，不过既然大家耐着性子看到这里，我也提个愿望：希望大家熟悉fortran之后也能如我这般做些力所能及的事情，帮一下后来者。不一定要在人烟稀少的瀚海星云Fortran版，别的什么地方都可以，哪怕只是在现实中教教后辈也是美事；最好对受益的人也提这样的一个愿望，这样一点点传播开去，世界就更美好了～
四、修改记录
2011.04.07 原版。
2011.04.08
补充了另外一个IDE的简介，Code::Blocks；
发觉对gfortran的评述有失偏颇，故引用dongyuanxun回复，重新修改；
引用IceAge的回复，简略补充了自动编译设置工具cmake和调试工具IDB、GDB。
