原创：win64系统gfortran编译lapack-3.3.0流程

myleader

因为工作需要，所以研究了一下在win64系统编译lapack的方法，不算十分成功，欢迎大家跟帖讨论。

lapack是目前世界范围内使用最广泛的计算软件包，大量的工具都是基于lapack来构建的，也有大量的开源软件基于这个软件包。为了能够使用这些工具，更是为了学习研究开源软件，我找了一下64位win7平台编译好的lapack，在
http://icl.cs.utk.edu/lapack-for-windows/
有人已经准备好了编译好的lib文件，不过我打算自己学习一下，所以试一试。

实际上3.1.1已经有人做好了VC的proj文件，直接用就可以了，不过新版的没有，所以我只好自己再想办法。
http://gcc.gnu.org/wiki/LAPACK%20on%20Windows
有一些工具，不过仅支持到3.2.2，为了编译最新的3.3.0我只好自己想办法了

http://blog.csdn.net/changzz2008/archive/2009/05/24/4212047.aspx
提供了一些提示信息，不过太简单了

lapack的网站和软件包内的文档并没有说明在win64平台下如何编译，不过说实在的既然田纳西大学都已经做好了win64的静态库，说明还是有办法的。于是参照linux下的方法在win64系统进行处理。

首先要准备3样软件
1）lapack的源代码，可以在http://www.netlib.org/lapack/下载，我使用的是3.3.0
然后解压到某个目录%lapack-3.3.0%

2）编译器。可选的编译器不多，win64平台下能用的也就是intel、PGI和gfortran这么3种，微软的Visual Studio没有fortran编译器。考虑到版权原因，更是因为intel的编译器个头比较大，而且在下从来没用过，所以选择gfortran

GCC目前最新的版本有4.5.1，windows平台的移植版本叫mingw，以前只有32位的，现在也有64位的了。在mingw的官方网站这个软件被拆分成数十个包，美其名曰工具链，目的是为了减少我的下载量。图省事我下载了tdm版本的
http://tdm-gcc.tdragon.net/download
由于我要在win64平台编译64位的库，所以直接选择64位的编译器比较方便。这里提供了2种GCC，sjlj和dw2版本的，这两个版本的异常模型不一样，虽然mingw官方提供的是dw2，不过tdm推荐win平台下使用sjlj，更主要的是64位的tdm只有sjlj版本，所以我选择sjlj。Bundle installer包含了c/c++的基本开发工具，该有的都有了，直接下一步就好，注意其中有一项是设置环境变量，务必选中；如果没有设置的话就要手工设置，把mingw的bin目录添加到系统环境变量PATH中。fortran没有包含在内，把那个页面往下拉，找到fortran的部分，一并下载来，然后解压缩到mingw的安装目录就可以了，保持其目录结构。

3）cmake
http://cmake.org/cmake/resources/software.html
这是一个配置工具，类似于configure和autotools，用来生成makefile的，详细的资料可以自己去查。官方网站提供了win32版本的下载，不仅如此，在这个版本中还有一个图形工具，非常方便。

这个软件随便解压缩到哪里就可以用了。

下面开始正式开工，首先在lapack-3.3.0中有一些问题，居然还有3.2.2的版本号残留，这一点我不能忍受，于是找到CMakeLists.txt，里面55-58行是版本号信息，更正过来；后面还有一些网址写的不对也更正过来。还有一个make.inc.example，把它更名为make.inc，第4行是版本信息，第5行是日期，全部更正过来，3.3.0是2010年12月发布的。第10行的SHELL写的是linux系统下的shell，win64系统下改成SHELL = cmd.exe；14行的PLAT标记可以改也可以不改，我改了；第23行OPTS参数设置为-O2，注意是字母O，不是数字0；最后67到70行设定输出文件名，我试过改了也没什么用。其实软件包里面还包含一个原始的Makefile，不过cmake处理之后这个原版的Makefile会被覆盖掉，所以没有改的必要。

第一步：运行cmake的gui工具，选择源代码目录，就是刚才解压缩lapack的目录。接着设定编译目录，其实这个目录就是放cmake生成的Makefile文件的地方，就设定成和源代码目录在一起吧。然后会弹出一个对话框，让你选择编译工具，既然我们选择mingw编译器，那自然就选mingw了。下面的四个选项比较高级，其实默认的就可以，如果你想让编译器针对你的cpu做特殊优化也可以选择最后一个，在新的对话框中设定你的cpu，具体的参数可以参照官方文档
http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
不过既然我们已经选择了x86_64的gfortran，那么就没必要设置那么多了，直接用默认设置就可以。

然后点击configure，cmake就会自动读取CMakeLists.txt，并根据其中的内容生成CMakeCache.txt，然后界面中间的表格中会出现几个变量，他们的具体含义可以看考官方维基
http://www.cmake.org/Wiki/CMake_Useful_Variables
BUILD_SHARED_LIBRARY我没选，因为我想要静态库。CMAKE_BUILD_TYPE我填了Release。CMAKE_INSTALL_PREFIX就是最后生成的库的位置，你希望生成的库文件放在哪里就设定哪里。BUILD_TESTING可以不选，不过如果你足够勇敢就选吧，其实就是测试一下，对最后的结果没什么影响。根据cmake的文档，可以添加其他参数，不过我偷点懒就不添加了。

修改完成后再次点击configure，这下所有红色条目都变成白色了，generate按钮可以点了，这时点击generate，一个makefile就生成了。

接下来进入命令行，进入lapack的解压缩目录，然后敲命令mingw32-make，如果之前gcc安装正确，确切的说是环境变量已经设置好了，那么系统会自动找到mingw32-make.exe并正确执行，如果提示找不到，请将gcc的bin目录添加到环境变量PATH中。然后就是漫长的等待，你会看到命令行窗口上的字符一行行的滚上去，等待了大概有20分钟，就会编译好了。

不过这时还只是一些目标文件obj，还没有生成库文件，还要再进行一步，在刚才那个命令行窗口敲命令mingw32-make install，然后就会看到提示信息滚上去，最后会有提示信息库文件安装到你刚才在cmake中设置的CMAKE_INSTALL_PREFIX中。

然后到CMAKE_INSTALL_PREFIX目录下去找把，你会找到blas.a(547k)和lapack.a(7134k)，这两个就是x86_64的lapack库文件。扩展名是不是lib不重要

其实我的编译还有一些问题variants和tmglib没能编译出来，应该是在cmake中设定参数，不过我没找到该怎么设定，如果哪位大虾找到了，务必分享一下。

fox000002

不错，有空也用 MinGW64 编译看看

temgy1986

支持原创. 最近也在搞一些并行计算软件, MINGW + MSYS 确实很强大.

myleader

注意cmake当中那个编译动态库的勾不要选，因为这样会编译出错。

动态库的编译方法如下，首先编译好静态库.a，然后再创建一个临时文件夹tmp

在命令行进入这个目录，然后
ar x ../blas.a
如果你的静态库文件名不是blas.a，那就把你的文件名输进去。接着回到原来的目录，也就是tmp的上一级
gfortran -shared -Wl,-soname=blas.so -o blas.so tmp/*.o
这样动态库blas.so就出来。lapack的方法类似，先清空tmp目录，接着进入tmp目录
ar x ../lapack.a
cd ..
gfortran -shared -Wl,-soname=lapack.so -o lapack.so tmp/*.o -L. blas.a
这样lapack的动态库也出来了，然后把.a和.so文件扔到mingw的lib目录就可以在mingw中用了
不过这个库在vc中使用会有问题，如果想在vc中使用，还需要一些处理。
首先在生成动态库的时候，把.so换成.dll，这样就会生成blas.dll和lapack.dll
然后在命令行运行mingw的工具
pexports blas.dll>blas.def
pexports lapack.dll>lapack.def
然后使用vc的命令行工具，就是vc开始菜单里面那个visual studio tools->command prompt，然后运行
lib /machine:x64 /def:blas.def
lib /machine:x64 /def:lapack.def
这样就会生成新的blas.lib和lapack.lib，把这两个lib和dll放到vc的目录就可以用了

我用armadillo试验了一下，armadillo的网址在
http://arma.sourceforge.net/
软件包里面自带了两个例子，其中第二个例子要用到lapack库，我们用之前生成的blas.dll, blas.lib, lapack.dll, lapack.lib替代其自带的库文件（1.1.0版自带的好像是lapack-3.1.1，intel编译器编译出来的），然后在第二个例子的项目中设定链接我们自己编译的库文件，编译运行，结果正确。

说实在的，我觉得在windows下还是vc比较好用，而armadillo是对lapack进行c++封装中做的最让人舒服的。在armadillo自己的文档中说自带的库文件是从http://www.fi.muni.cz/~xsvobod2/misc/lapack/
下载的，不过这里目前也只有3.2.1版。lapack -3.2.1版里有一些bug，在3.2.2版中修正了，在官方的release notes中有说明，所以我建议大家还是升级一下比较好；另外从3.3.0版起lapack终于变成完全线程安全的了，所以我也建议大家升级。另外armadillo提到的其他下载站点下载的库文件斯坦福大学的版本古老，田纳西大学的无法在windows下配合armadillo使用，而intel和amd的有版权问题，所以本人写了这篇文章，希望能够帮助大家。

myleader

上文讲述了如何编译lapack及其自带的blas，使其可以在VC中使用。这里再说明一下如何用更快的blas来替代lapack自带的
实际上lapack自带的blas速度并不快，atlas是一个比较快的实现，不过这里我要说的是被评为世界最快blas的gotoblas，据说比intel的MKL还快
gotoblas的源代码在这里
http://www.tacc.utexas.edu/tacc-projects/gotoblas2/
lapack的源代码在这里
http://www.netlib.org/lapack/

32位版编译：
首先必须安装msys和mingw32，不能使用mingw64，否则会自动编译64位版

msys和mingw的官方下载站是
http://sourceforge.net/projects/mingw/
把软件拆成了一大堆包包，下载起来特别麻烦，lzma压缩格式可以用7-zip打开
在国内有人制作了集成版
http://code.google.com/p/pcxprj/
http://code.google.com/p/msys-cn/
注意一定要把msys和mingw安装在两个不同的目录，千万不能混用，有一些通用的包比如binutil之类的，绝对不要混用，要不然有你受的。我使用的msys是官方版，mingw32和mingw64我用的是tdm版
http://tdm-gcc.tdragon.net/download

通过VC的命令行工具——就是开始菜单里VC目录下Tools里那个comman prompt——启动，进入msys的安装目录，执行
\>msys.bat -norxvt
这样就可以同时使用VC命令行工具和msys中的bash，别忘了检查一下gcc对不对
$ gcc -v

编译gotoblas：
进入gotoblas的源代码目录，输入命令
$ make BINARY=32 USE_THREAD=0
注意不能使用mingw32-make，实际检验会出错，这两个make还真是不知道怎么搞的，居然对makefile的解释不一样。另外一定要指定BINARY=32，否则程序会自动检测你的cpu，现在大多数同学的cpu都是64位的了吧，那它就会自动编译64位的，而这会有问题，具体的下文说

然后会在gotoblas目录生成libgoto2_opteron-r1.13.lib，这个是编译程序自动检测cpu得来的，如果cpu不是AMD的opteron，那后缀会不同，另外cpu的其他优化参数以及编译器也会自动设定。并在exports目录生成libgoto2.dll、libgoto2.def和libgoto2.lib，如果不是从VC命令行启动的bash，那么不会得到lib文件。我喜欢把它们改一下名字，libgoto2_mingw32.dll和libgoto2_mingw32.def，然后在命令行输入
$ lib /machine:x86 /def:libgoto2_mingw32.def /out:libgoto2_mingw32.lib
这样就生成了VC可以使用的libgoto2_mingw32.lib和libgoto2_mingw32.dll

编译lapack：
把libgoto2_opteron-r1.13.lib拷贝到lapack的源代码目录，然后修改make.inc
BLASLIB      = ../../libgoto2_opteron-r1.13.lib
这里非常重要，让lapack使用gotoblas，而不是自带的blas
再继续修改
PLAT = _mingw32
...
FORTRAN  = gfortran -fimplicit-none
OPTS     = -O2 -mmmx -msse -msse2 -msse3
DRVOPTS  = $(OPTS)
NOOPT    =  -O0
LOADER   = gfortran
LOADOPTS = -O2 -mmmx -msse -msse2 -msse3
默认的-g开关会生成debug信息，如果你想要debug版就保留，不过我可没本事去debug这么基础的数学库，另外之前普遍流传的-fPIC开关已经被开启，不需要再加
然后保存，回到命令行进入lapack目录，输入
$ mingw32-make
这里最好使用mingw32-make，实践检验msys的make会出错
然后会在lapack目录生成lapack_mingw32.a
然后在命令行输入
$ echo EXPORTS >> lapack_mingw32.def
$ nm lapack_mingw32.a | grep ”T” | sed “s/.* T //g” | grep -v '' | sed 's/^.//g' >> lapack_mingw32.def
那个笑脸是冒号和美元符号。这样就得到了def文件，第一个命令是在lapack_mingw32.def的第一行插入EXPORTS，后面的命令是提取lapack_mingw32.a中的函数声明，并把它追加到lapack_mingw32.def中，这两个命令一定要在lapack_mingw32.def不存在的时候连续执行，如果错了可以编辑lapack_mingw32.def或者干脆删掉lapack_mingw32.def重新执行这2个命令，如果你想知道第2个命令到底干了什么，可以不使用管道也就是不用“|”逐个执行，然后你就明白了，注意不要省略引号中的空格

接着
$ gcc -shared -o lapack_mingw32.dll lapack_mingw32.def lapack_mingw32.a -lgfortran -L. libgoto2_opteron-r1.13.lib
这样就得到了lapack_mingw32.dll
最后在命令行输入
$ lib /def:lapack_mingw32.dll.def /out:lapack_mingw32.lib /machine:X86
就得到lapack_mingw32.dll和lapack_mingw32.lib

也可以用dllwrap命令
dllwrap --export-all-symbols SRC/*.o INSTALL/slamch.o INSTALL/dlamch.o -lgfortran -L. libgoto2_opteronp-r1.13.lib --output-def lapack_mingw32.def -o lapack_mingw32.dll
这两种方法生成的dll会有一些差别，dllwrap生成的dll会大一些，对libgfortran-3.dll的依赖也会多一些，这是从斯坦福大学的lapack下载页面参考而来，至于slamch.o和dlamch.o我并没有仔细研究

如果你担心上面的方法会漏掉什么对象的话，另外一种方法是把lapack_mingw32.a中的对象文件都解出来，然后编译成动态库
$ mkdir tmp
$ cd tmp
$ ar x ../lapack_mingw32.a
$ cd ..
$ dllwrap --export-all-symbols tmp/*.o -lgfortran -L. libgoto2_opteronp-r1.13.lib --output-def lapack_mingw32.def -o lapack_mingw32.dll
这样得到def文件和dll文件，再制作lib文件

也可以直接从lapack编译得到blas，除了要在make.inc中进行修改以外，还需要在makefile中修改，注释掉原来的
lib: lapacklib tmglib
而采用
lib: blaslib variants lapacklib tmglib
然后在命令行输入
$ mingw32-make
最后就编译得到blas_mingw32.a和lapack_mingw32.a，从这两个静态库得到动态库的方法和上面一样，只是在得到lapack动态库时要链接的是blas_mingw32.a
$ gcc -shared -o lapack_mingw32.dll lapack_mingw32.def lapack_mingw32.a -lgfortran -L. blas_mingw32.a

http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=908
http://www.wfu.edu/~cottrell/lapack/
提供了一些编译动态库的方法，经实践检验，mingw配合lapack-3.3.0做不了，所以大家还是按照这个帖子来吧

关于优化参数：
优化参数中-O2和-O3几乎没有任何差别，实际检测mmx、sse、sse2、sse3指令集带来的效果也不大，也许是没有碰到相关的函数吧。其他的优化选项请看
http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/
在PCX的博客，对编译器优化进行对比的帖子
http://www.cnblogs.com/xunxun1982/archive/2010/08/26/1808623.html
给出了一些优化参数，不过我奉劝大家别用，都是些很危险的开关，毕竟数学库是要算有用的东西的，算错了可不是闹着玩的

关于多线程，gotoblas中USE_THREAD=1可以开启多线程，不过我个人还是更愿意使用单线程基本库，并在自己的程序中设定多线程甚至多进程，这样更容易把握

接下来测试一下，VC没有自带fortran编译器，所以首先下载一个lapack的c++封装，我最喜欢的armadillo
http://arma.sourceforge.net/
用得到的libgoto2_mingw32.lib、libgoto2_mingw32.dll、lapack_mingw32.dll和lapack_mingw32.lib替代掉armadillo自带的库文件就可以用了。

实际测试代码如下
#include <iostream>
#include <ctime>
#include "armadillo"

using namespace std;
using namespace arma;

void main()
{
        int size=1024, N=10;
        clock_t start, end;
        mat A = randu(size,size);
        mat B = randu(size,size);

        mat Z = zeros(size,size);
        cout <<"start"<<endl;
        start = clock();
        for(int i=0; i<N; ++i)
        {
                Z = A*B;  //  or Z = A+B+C ... etc
                cout<<i+1<<endl;
        }
        end = clock();
        cout << "time taken = " << 1.0*(end-start)/CLOCKS_PER_SEC << endl;
        system("pause");
}
编译器是VC2010，release优化参数。如果采用armadillo自带的库文件或者从http://www.fi.muni.cz/~xsvobod2/misc/lapack/下载更新版，那么进行10次1024*1024大小矩阵的乘法在AMD5000+上单线程需要35秒，armadillo中推荐的其他下载点的库我没有实验，因为田纳西大学的不能配合armadillo用，而斯坦福大学的太古老了，估计不会更快。如果是这里编译出来的自带blas和lapack，需要38秒，我在使用gotoblas之前还以为这3秒也就是8.6%的速度差距是由于Svoboda使用了更快的blas库带来的，现在看来是intel的编译器带来的。64位MATLAB执行同样的操作需要4.57秒。那么gotoblas需要多久呢？如果是这里编译出来的gotoblas，仅需要5.26秒，比lapack自带的blas强太多了！7倍的速度差距啊！不过还是和AMD的ACML有很大差距14%，如果在编译gotoblas时开启多线程，那么这段测试代码的执行时间可以缩短到2.7秒，比MATLAB的ACML快很多。不管怎么说，在开源数学包中，gotoblas实在是翘楚，我认为重新编译gotoblas是非常值得的。

64位版本编译：
实践检验mingw64可以编译出来64位gotoblas，不过在编译lapack时xlintstz的complex16 equation routine测试通不过，所以我只好放弃了64位的gotoblas，最主要的缺憾是mingw32的三角函数特别慢，根据
http://bbs.pfan.cn/post-350022.html
的讨论，mingw64的三角函数是很快的，可惜用不了了，不过有兴趣的同学可以尝试一下pcx的mingw32，他把mingw64的三角函数移植到mingw32了

如果你不在乎这种问题，一定要强行使用64位gotoblas的话，编译方法类似，首先把mingw32换成mingw64。怎么换？把旧的删掉，安装新的就好了。因为mingw32编译器关闭了-m64参数，无法编译64位程序，这就是为什么在编译32位gotoblas时一定要设定BINARY=32的原因。msys不用换。然后在编译gotoblas时使用命令
$ make BINARY=64 USE_THREAD=0
如果你想要多线程，那么USE_THREAD=1
最后会生成libgoto2_opteron-r1.13.lib，文件名和32位的一致，后面制作dll和VC用lib时，方法和32位类似，只是lib命令的/machine参数改为x64，另外我建议把后缀改成mingw64
编译lapack时，修改make.inc
BLASLIB      = ../../libgoto2_opteron-r1.13.lib
...
PLAT = _mingw64
...
FORTRAN  = gfortran -fimplicit-none
OPTS     = -O2 -m64 -mmmx -msse -msse2 -msse3
DRVOPTS  = $(OPTS)
NOOPT    = -m64 -O0 #我上lapack论坛上问过，有人回答说这个-m64加上以后可以解决64位测试通不过的问题，不过实际检测还是通不过
LOADER   = gfortran
LOADOPTS = -O2 -m64 -mmmx -msse -msse2 -msse3
然后在命令行输入
$ mingw32-make lapacklib
这样可以不做测试，避免编译测试过程中出错，不过这不能避免未来使用中遇到这个错误
接下来制作VC库的方法和32位一样，只不过lib命令的/machine参数改为x64而已

如果想要制作64位版本lapack自带blas，首先把编译器换成mingw64，然后按照64位方法修改make.inc，并按照32位方法修改makefile，然后在命令行
$ mingw32-make
就得到了，接下来接下来制作VC库的方法和32位lapack的一样，只是lib命令的/machine参数改为x64，后缀改成mingw64（当然后缀可以不改）

dongyuanxun

补充一点，我发现mingw64 crt的三角函数测试速度已经堪比intel的速度了（http://code.google.com/p/pcxprj/downloads/list，我已经上传了较新版的gcc/gfortran4.5.x的X86和X64版），当时慢的原因是因为我没有开启自动并行化，而当时测试intel编译器时是打开了自动并行的，-ftree-parallelize-loops=n
n为你的cpu的核心数。在我的电脑上gcc/gfortran使用-O3 -fivopts -ftree-loop-linear -ftree-vectorize -fforce-addr -fomit-frame-pointer -fno-bounds-check -funroll-loops -ffast-math -march=native -mfpmath=sse -mmx -msse -msse2 -msse3 -ftree-parallelize-loops=2
速度已经超过intel编译器的（/fast /O3 /Ot /Og /Oi /Qipo /QxHost /arch:SSE3 /Qunroll /Qvec /Quse-intel-optimized-headers /Qparallel /fp:fast=2 /Ob2 /GT /GA）。
lz可以研究下多平台兼容的gotoblas的dll如何编译，我发现开启多平台时，goto的源码有个赋值错误，而且生成dll需要一个入口函数，我在引入入口后生成的dll总是不能正常使用。

liysman

好专业的讨论啊，我提一个小小的问题，用Cmake生成makefile编译出的库文件7M多，我用lapack-3.3.1自带的makefile编译的库文件却达到15M左右，优化选项都是-O2，mingw64，为何大小差距这么大呢？

铁道科学

好帖，mingw或cygwin在跨平台方面很爽，不过一直担心性能问题，不知道楼主有没有相关经验，如果不存在此类问题的话，改天我把程序也移植一下，不然天天在虚拟机跑程序。

myleader

liysman 发表于 2011-10-30 17:14
好专业的讨论啊，我提一个小小的问题，用Cmake生成makefile编译出的库文件7M多，我用lapack-3.3.1自带的mak ...

你的提问还真是让我大吃一惊，我原以为两种方法生成的文件应该一样。

特意测试了一下。如果你采用官方blas，两种方法生成的静态库文件是完全一致的，不仅大小相等，md5码也完全相等。注意，lapack自带的Makefile中是有-g开关的，也就是说生成debug版，这样就文件就大多了。lapack的静态库7M正常，我编译出来的也是这么大，debug版我没测试过，我也不打算debug这么基础的数学库。而我是用的编译器是xunxun1982的静态套装，生成的文件本来就要大一些，如果你用的是TDM的动态套装，文件应该小一点才对。

Ray Linn的编译器套装我没有用过，没有发言权。

德克萨斯大学以BSD协议发布了gotoblas2-1.13版之后，宣布gotoblas停止开发，并鼓励其他人开发分支版。中科院Zhang Xianyi做了一个fork版openblas，修正了gotoblas中一些安装脚本的bug，尤其是官方版中DYNAMIC_ARCH的bug被修正了，并加入了龙芯3A的支持，你可以试试。不过不要开启-O3优化，会出错的。

另外本人个人不支持使用GSL，他的许可协议是严格的GPL许可协议，不能用于开发私有软件。而且GSL本身的api也不友好，运行效率又不高，虽然宣称了很多功能，但是各个领域的专业软件包都比他做得好。GSL更适合作为一种象征。

如果你使用Fortran，那么建议你直接使用lapack，如果你使用C++，推荐使用armadillo+lapack/gotoblas或者干脆eigen，在我写过的文章中都有介绍，尤其推荐eigen，它可以避免很多多语言混合编程带来的莫名其妙的问题，而且速度快得超乎想象。

myleader

铁道科学 发表于 2011-11-2 20:14
好帖，mingw或cygwin在跨平台方面很爽，不过一直担心性能问题，不知道楼主有没有相关经验，如果不存在此类 ...

我的经验也不是很多，其实是因为公司里电脑没有管理员权限，装不了盗版软件，所以才不得以研究这个东西的。别人的测评结果大多是VC比mingw编译速度快，而且编译出来的东西执行速度也快，毕竟mingw是移植的，没办法

我也做过一些测试，不过并不严格。如果不涉及windows操作，纯粹的数学运算的话，mingw编译出来的程序更快，大概差4%左右，VC参数是release /O2，mingw参数是-O2 -mmmx -msse -msse2 -msse3，这可能是因为VC对新硬件的支持不够造成的，如果mingw不加指令集优化参数，VC要快一些。如果涉及到三角函数，mingwrt的速度比不上VC，而VC比不上mingw64crt，这也是我选择dongyuanxun的套装的原因。另外VC对openmp的支持似乎不是那么好，而mingw的支持堪称完美。

如果涉及windows操作，比如图形界面、图形图像、文件IO等，VC就比mingw快很多，甚至会翻倍。

铁道科学

myleader 发表于 2011-11-3 23:51
我的经验也不是很多，其实是因为公司里电脑没有管理员权限，装不了盗版软件，所以才不得以研究这个东西的 ...

谢谢楼主这么耐心的回答，你的这些经验相当有用。曾经我移植过我的程序，用VC C++编译后慢的不是一丁点，因为移植过程中替换掉了多个GCC自带函数（网上当来的），所以也不好说是啥缘故导致变慢的。不过当时在论坛和人请教过，据别人经验：VC在数值计算比较慢，比不上GCC的，而intel的则更快些。