回 帖 发 新 帖 刷新版面

主题:【Fortran入门2/3】Windows、Linux下的Fortran编译器

  这篇文章是我刚刚在科大论坛写完的,本着分享的愿望,姑且忘却一己固漏,厚颜转发到此处。在pfan.cn已经注册了挺久了,在Fortran版更是获益良多,此前一直潜水,希望这次能略微回报一二。原文有论坛禁用关键字,只转了链接了事。这次发现被加精华,只好仔细检查把禁用字眼去除,全文转发了。真诚感谢论坛上各位朋友的优质回帖~

原帖地址:
http://fbbs.ustc.edu.cn/cgi/bbscon?bn=Fortran&fn=M4D9D9CFC&num=5919



    【Fortran入门2/3】Windows、Linux下的Fortran编译器简介及推荐 v2.0(2011)



  这篇文章同样是为了支援新版主而写,想尽力统一回答一下版上问得最多的一类问题:Windows、Linux下都有些什么常用的Fortran编译器?

  见知所限,我说的未必公允,也肯定有缺漏,厚颜写出来只是为了抛砖引玉将问题彰显,给出个尚可的解决方案,后来人就不用再在版上浪费时间在这些基本问题上了。如果有牛人进一步纠正、补偿,那就更完满了。我之前的《Ubuntu10.04_i386 下安装 ifort 11.1.072》是这种用意,以后如果有空,写得入门类文章也会是这种用意。好不容易有了版主,而且愿意做这么多,由衷期待版上的其他朋友也一并参与进来,助他一臂之力,一起留下些可供后来者参考的珍贵资料~

  在开始前,先得点明一个很基本的观念:编译器(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怀抱的是一篇著名的文章:王垠《完全用 GNU/Linux 工作》,强烈推荐。
  (http://www.chinaunix.net/jh/4/16102.html)



二、Linux

  之前提到过,Windows下面的Fortran发行版,多半是整合了IDE的商业版,价格不菲。而Linux下则是完全不同的氛围,常用的编译器清一色都是免费,甚至开源。缺点只是:没有集成统一的IDE,在可视化、在编辑调试方面似乎不那么方便。——但事情不是这样的。

  Linux下有伟大的开源IDE,Eclipse可以替代VS;更有其他更自由更高效的解决方案,——只要你愿意花时间学习。

  当然,爱怎么折腾都全凭个人喜好。实际上,我实验室里面的师兄们都是简简单单随便一个文本编辑器+编译器就了解,纯手工维护。这里那么多方案,只是提供更多选择的可能性,让大家知道,离开Windows来到linux其实是一种解放。

  我自己用的Linux发行版是32位的Ubuntu10.04,下面也主要以之为例。以下提到的所有软件,在不同发行版中照样可用,大家不必担心。



1)两种解决方案:IDE or DIY

  先说IDE,大名鼎鼎的跨平台、自由、集成开发环境Eclipse就有专为Fortran设计的插件Photran,支持所有常见的Fortran编译器,如ifort、gfortran、g95等等。虽说一时间还比不上Windows下的VS,但已经相距不远了。(注,不是说强大的Eclipse比不上VS,而是身为插件的Photran还不够成熟,Photran+ifort还比不上IVF)。关于Eclipse和Photran可以自行Google之。下载也容易,Ubuntu的软件中心就有,虽然版本要旧一点,但胜在方便。
  (http://www.eclipse.org/)

  关于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公司提供的模拟器。
  (http://asc.2dark.org/node/8)

  我自己用的是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也是用它编译的,感兴趣的可以试用一下。”
  (http://www.cnblogs.com/sinojelly/archive/2010/05/22/1741337.html)



  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。

回复列表 (共46个回复)

沙发

综述得挺详细的, 赞一个. 可惜这里没有版主, 帖子还是会沉的. 新来的朋友还是会问"用什么编译器"...

板凳

科大很久没去了。
不过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一下就行了。

3 楼

另外,补充一下,gcc/gfortran的调试是个硬伤,不如intel编译器的调试器好,所以对个人的调试水平比较高。虽然可以使用archergdb来代替gdb,显示还是没有ivf的好。

4 楼

再补充一下,Fortran的IDE可以使用跨平台的Code::Blocks,代码完成,函数跳转都挺不错。

5 楼

楼主写的很好啊,大体上跟我的经验差不多,我在Linux下玩Fortran, 喜欢的3个编译器是gfortran, intel, pgi, 我们这里有个Power6小集群,所以也用过xlf,版本12.1, 如果说intel编译的程序比gfortran快个两三倍的话,xlf就是3倍以上了,不过还是不喜欢xlf。

没有用过什么IDE,一直只用vi, 编译就是命令行。make脚本写过一些,都比较简单。

看了楼主的帖子,我在书架上翻了翻,找到了楼主说的那本oreilly《emacs》第2版,满是灰尘,这本68元的书我买回来竟然从未看过。

对Fortran最大的两点遗憾是 gdb对Fortran支持不好,以及Fortran不能像C那样只要在使用一个变量前声明即可,搞的Fortran程序总是在一开始声明大量变量,这不是现代编程风格。

渐渐地,这里高手很多了。

6 楼

[quote]楼主写的很好啊,大体上跟我的经验差不多,我在Linux下玩Fortran, 喜欢的3个编译器是gfortran, intel, pgi, 我们这里有个Power6小集群,所以也用过xlf,版本12.1, 如果说intel编译的程序比gfortran快个两三倍的话,xlf就是3倍以上了,不过还是不喜欢xlf。

没有用过什么IDE,一直只用vi, 编译就是命令行。make脚本写过一些,都比较简单。

看了楼主的帖子,我在书架上翻了翻,找到了楼主说的那本oreilly《emacs》第2版,满是灰尘,这本68元的书我买回来竟然从未看过。

对Fortran最大的两点遗憾是 gdb对Fortran支持不好,以及Fortran不能像C那样只要在使用一个变量前声明即可,搞的Fortran程序总是在一开始声明大量变量,这不是现代编程风格。

渐渐地,这里高手很多了。[/quote]

主要是动态数组gdb支持不好,所以要使用archergdb,但是archergdb不是紧跟gdb的trunk的,所以有些特性也发挥不出来,我曾经试图把archergdb的补丁分离合并到gdb里,编译未果,要改太多东西了。
vi基本不用了,vim用的多,比vi支持更多的功能。emacs也用一些,但用着用着老想把它用成vim。
编译器的性能比较很难说,在机群上没有用过,不过在PC上intel和gfortran性能还是相差不大的,有些内部函数性能和编译器无关,而是和C库实现有关,这个AMD/Cygwin/Redhat那里都有很多未接受的提高性能的补丁(有的和版权有关,有的缺少测试)

7 楼

gfortran 还是最受欢迎的,因为它可玩性强,我很希望自己或者其他网友能看懂gfortran源码,规模其实也不是特别大,gcc的中后端可以不去研究。

在此之前必须先学习c,以及编译原理,以及程序语言的理论。学习量还是比较大的。c++比较复杂庞大,但是c是一个较小的语言,容易上手。

觉得大家的水平渐渐开始接近老外了。

google fortran讨论组封了整个中国,这是我们最大的损失,没机会向大师们学习了。都怪一帮烂人老发广告帖子。

8 楼

个人发表点小感想:
GFORTRAN让我最头疼的一点就是~~~它的文件IO效率比IFORT底的不是一星半点~~~~
之前我也发过求助贴,当时董兄也是相当竭尽全力的帮助我,我相当感激:)但最后发现,程序的运行效率损失竟然不是在做解非线性方程上,而是在读写文件上~~~~(我用的是MSWIN系统)
当时我就晕菜了~~~~

不过个人还是挺喜欢C::B+GF的:)只是不太清楚文件IO的效率怎么就会比IVF差那么多~~~~~

9 楼

此贴被加精了~~~
是版主复出还是管理员来了?

10 楼

[quote]gfortran 还是最受欢迎的,因为它可玩性强,我很希望自己或者其他网友能看懂gfortran源码,规模其实也不是特别大,gcc的中后端可以不去研究。

在此之前必须先学习c,以及编译原理,以及程序语言的理论。学习量还是比较大的。c++比较复杂庞大,但是c是一个较小的语言,容易上手。

觉得大家的水平渐渐开始接近老外了。

google fortran讨论组封了整个中国,这是我们最大的损失,没机会向大师们学习了。都怪一帮烂人老发广告帖子。[/quote]
其实编译器那一块儿代码并不是很多,如果加上binutils和CRT,代码量就上去了。
只是C语言虽然较C++简单,但是使用了大量的宏,搞得人很头疼,这点不如Clang/LLVM的代码管理(因为是C++写的,不过体积也增加了数倍)。

关于google fortran讨论组,这个我一直翻墙……

我来回复

您尚未登录,请登录后再回复。点此登录或注册