24小时热门版块排行榜    

查看: 2385  |  回复: 18
【奖励】 本帖被评价4次,作者波不动增加金币 3
当前主题已经存档。

波不动

木虫 (正式写手)


[资源] 【原创】简单测评Win32下各种C/C++常用编译器数值计算性能

一、测试的编译器的有:

Microsoft VC++6.0编译器,cl.exe版本12.0.8168.0。
Microsoft VC++2008编译器,cl.exe版本15.0.30792.1。
Intel C++9.0编译器,icl.exe版本未知。
GUN Mingw32 G++(GCC)编译器,Mingw版本5.1.6。
Borland C++ Builder 6编译器,bcc32.exe版本5.6.4.0。

二、测试环境和参数:

CPU:AMD普通双核处理器,主要关注相对性能的比较。
开发环境:Code::Blocks svn Build,对同一个程序分别对手工替换设置各种编译器进行编译。编译为Release版本的程序,参数上,全部选择为普通的O2(速度优化),其他一律不选,比如Intel专门针对自己处理器的优化等等都未选。


三、测试项目:

一个声波波动方程正演程序,数据量较大,计算中有开根号,开平方运算,同样测试计算速度。

四、测试结果:

编译器名称                                            计算时间       
Microsoft VC++6.0编译器                          4.250 s
Microsoft VC++2008编译器                       2.671 s
Intel C++9.0编译器                                   1.798 s
GUN Mingw32 G++(GCC)编译器                 8.265 s
Borland C++ Builder 6编译器                      4.156 s

五、测试总结:
结果很显然,从计算速度上来说,Intel C++9.0编译器占据了较大的优势,在没有专门针对处理器优化已经本人AMD双核CPU上的测试,还能达到仅仅1.798 s的计算速度,确实非常令人咋舌,如果再进一步优化性能还会有更进一步的提高。另外Microsoft VC++2008编译后的执行效率也非常之高,仅仅比Intel编译器多了1秒的时间。至于VC++6.0和BCB6.0这两位老将确实已经是风华不再了。计算时间比前者多出了两三倍之多。。。而GUN Mingw32G++的的效率是最差的,这是让人觉得很奇怪的事情,而且不管我怎么设置,都进不了8秒的计算时间,实在是搞不懂。说是说Win32下也可以用GCC了,但是如此差的性能,实在是感觉不用也罢。或者哪位高手能指出哪里出问题了?


综合下来,我个人还是推荐VC++2008编译器(除了以上优势还带有更多完整的警告调试功能),第二推荐Intel C++ 9.0(因为现在已经出到10 11 12了都,缺点是9.0以后的破解比较不容易拿到)。


最后声明,此项测试乃我本人的非专业简单测试,其中肯定有不少考虑不周或者不合理的地方,欢迎各位指出!

[ Last edited by 波不动 on 2009-12-7 at 00:25 ]
回复此楼

» 收录本帖的淘帖专辑推荐

编程

» 猜你喜欢

已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

★★★★★ 五星级,优秀推荐

置为资源帖。支持原创!
2楼2009-12-06 22:55:45
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

★★★ 三星级,支持鼓励

★ ★
波不动(金币+2,VIP+0):忘记加分了!谢谢支持! 12-7 00:21
(1)编译时间是如何获得的?

(2)是否考虑了“库”的问题?是静态还是动态(共享)?
这不仅与可执行程序的大小有关,而且和连接(Link)时间有关。
俺猜测,MinGW和BCB得到的文件大小一样,说明它们都静态连接了某个库。而VC6和VC2008,或是没用到这个库,或是用了动态连接(例如,交给了MFC*.DLL)。

请提供各个编译器的Makefile(VC也可以从工程文件得到makefile)。
这样,就能看出库的问题了。
3楼2009-12-06 23:34:39
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

波不动

木虫 (正式写手)


引用回帖:
Originally posted by yalefield at 2009-12-6 23:34:
(1)编译时间是如何获得的?

(2)是否考虑了“库”的问题?是静态还是动态(共享)?
这不仅与可执行程序的大小有关,而且和连接(Link)时间有关。
俺猜测,MinGW和BCB得到的文件大小一样,说明它们都静态连 ...

编程时间是在Code::Blocks环境下调试后自动计算获得的,就像在某个浏览器下打开一个网页自动会计算打开时间一样。

有道理呢。库文件的问题确实我没想到,但是这提醒了我~!在静态库和动态库的设置上肯定有问题~!有待我重新测试有修改测试结果。。。谢谢!

根据调试,发现确实不是那么回事,选择了静态库后,发现程序确实大了很多,再加上我感觉这项测试很不合理,所以删除之。

但是,不知道这和程序的运算速度有关么?为什么MinGW(最新版了)编译的效果这么差呢?有什么办法可以解决呢?



[ Last edited by 波不动 on 2009-12-7 at 00:06 ]
4楼2009-12-06 23:51:07
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖
★ ★
波不动(金币+2,VIP+0):谢谢!我都是用最后得到的程序计算时间做的测评,并未考虑编译时间。 12-7 00:23
另外,还有预编译的设置。
例如,在VC下的预编译,就是生成那个挺大的PCH文件。
如果VC用了预编译,而其他的没有,也不公平咯。
(如果头文件没有变动,那么预编译能大大减少编译时间,也就是用空间换时间咯)
VC的那个Rebuild All才能强迫预编译重新进行。
5楼2009-12-07 00:05:25
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

波不动

木虫 (正式写手)


★ ★
jjdg(金币+2,VIP+0):波版辛苦了! 12-7 00:35
引用回帖:
Originally posted by yalefield at 2009-12-7 00:05:
另外,还有预编译的设置。
例如,在VC下的预编译,就是生成那个挺大的PCH文件。
如果VC用了预编译,而其他的没有,也不公平咯。
(如果头文件没有变动,那么预编译能大大减少编译时间,也就是用空间换时间咯) ...

没有用预编译,所有的编译都是在Code::Blocks下,调用各种编译器运行的。另外,我没有统计编译的时间,因为感觉编译时间上比较的意义还不是很大,毕竟不是什么大工程。

界面如下:

6楼2009-12-07 00:11:00
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

zhaoxiaoqi

木虫 (著名写手)



波不动(金币+1,VIP+0):感谢你的评论!我也不是很明白,改天在Linux下用纯GCC再测试一下。 12-10 01:43
参考参考!
不知道正则表达式那个能力更强
瞎说几句
GCC会不会是因为在模拟LINUX的模式下工作的。就是说实际上是通过先生成LINUX的代码再转译linux的代码生成WIN的代码。
也会不会是因为MS和INTEL的两家的最终代码与硬件或系统内核的结合更好,毕竟两家的库文件的作者能近水楼台先得月。
7楼2009-12-10 00:10:38
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

holmescn

金虫 (正式写手)


★ ★ ★ ★
senlia(金币+2,VIP+0):欢迎参加讨论 12-14 18:15
波不动(金币+2,VIP+0):抛砖引玉啊,感谢您的评论,长见识了,希望你能常来呢,至于12是我搞错了! 12-14 19:46
首先,GCC慢是很正常的事。如果你已经O2,甚至O3过了,还是慢的话,那就是因为glibc这个破数值库的问题了。这个库是公认的数值计算超慢的库。所以不要用。GCC的优势在于:1、开源,不要钱,无版权问题。2、可跨平台编译,且支持的平台很多。目前还没有找到好的C/C++的数值库。Intel的MKL(Math Kernel Library)库是非常捧的,可惜在win下是要钱的。如果你能把icc9里的MKL库用GCC连接一下,可能会快不少。
另:Intel C++ Compiler现在不是才11.1吗?我刚下载了一个啊。在Linux下有非商业的licence,在win下没有。已经不用VS很多年了,又大,又不爽。改拜VIM教了。
8楼2009-12-14 14:06:45
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

★★★ 三星级,支持鼓励


senlia(金币+1,VIP+0):同时也是个技术活 12-15 11:45
这可是个体力活啊!
9楼2009-12-15 03:34:26
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

holmescn

金虫 (正式写手)


★ ★
senlia(金币+2,VIP+0):欢迎新虫!感谢您提出的问题和思路! 12-18 16:00
我没有这许多的编译器,(而且体力上也不支啊^_^),希望LZ能做这样一个实验,以验证我对glibc的猜想:
  用数值积分,或其它数值算法,不要计算只包含加减乘除,不包含其它如三角函数及指数、对数的运算。测试不同编译器的速度。看是不是有很大差异。
10楼2009-12-18 15:33:06
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

波不动

木虫 (正式写手)


senlia(金币+0,VIP+0):等待您的结果 12-18 21:32
引用回帖:
Originally posted by holmescn at 2009-12-18 15:33:
我没有这许多的编译器,(而且体力上也不支啊^_^),希望LZ能做这样一个实验,以验证我对glibc的猜想:
  用数值积分,或其它数值算法,不要计算只包含加减乘除,不包含其它如三角函数及指数、对数的运算。测试不 ...

其实我最早用积分算法测试过了,也只有加减乘除,但结果没有记录。可能肯定的是gcc的劣势依然明显无疑,谢谢你的建议。我会做一下这个测试的。
11楼2009-12-18 19:40:30
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

波不动

木虫 (正式写手)



jjdg(金币+1,VIP+0):波版果然厉害啊! 12-19 00:49
引用回帖:
Originally posted by 波不动 at 2009-12-18 19:40:


其实我最早用积分算法测试过了,也只有加减乘除,但结果没有记录。可能肯定的是gcc的劣势依然明显无疑,谢谢你的建议。我会做一下这个测试的。

全部是o2优化,一个令人诧异的结果,我不敢再测试了:
14.906   gun gcc
5.965    c++ 2008
10.218   bcb
8.437    intel
5.650    c++6.0

这次用的积分程序:
CODE:
#include
#include
#include
#include

// Function to be integrated
// Define and prototype it here
// | sin(x) |
#define INTEG_FUNC(x) fabs(sin(x))

// Prototype timing function
double dclock(void);

int main(void)
{
// Loop counters and number of interior points
unsigned int i, j, N;
// Stepsize, independent variable x, and accumulated sum
double step, x_i, sum;
// Timing variables for evaluation
double start, finish, duration, clock_t;
// Start integral from
double interval_begin = 0.0;
// Complete integral at
double interval_end = 2.0 * 3.141592653589793238;

// Start timing for the entire application
start = clock();

printf(" \n");
printf(" Number of | Computed Integral | \n");
printf(" Interior Points | | \n");
for (j=2;j<27;j++)
{
printf("------------------------------------- \n");

// Compute the number of (internal rectangles + 1)
N = 1 << j;

// Compute stepsize for N-1 internal rectangles
step = (interval_end - interval_begin) / N;

// Approx. 1/2 area in first rectangle: f(x0) * [step/2]
sum = INTEG_FUNC(interval_begin) * step / 2.0;

// Apply midpoint rule:
// Given length = f(x), compute the area of the
// rectangle of width step
// Sum areas of internal rectangle: f(xi + step) * step

for (i=1;i {
x_i = i * step;
sum += INTEG_FUNC(x_i) * step;
}

// Approx. 1/2 area in last rectangle: f(xN) * [step/2]
sum += INTEG_FUNC(interval_end) * step / 2.0;

printf(" %10d | %14e | \n", N, sum);
}
finish = clock();
duration = (finish - start);
printf(" \n");
printf(" Application Clocks = %10e \n", duration);
printf(" \n");

return 0;
}

12楼2009-12-18 22:09:22
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

holmescn

金虫 (正式写手)


★ ★
波不动(金币+2,VIP+0):好的,我觉得intel优化有就会有精度损失,但不知道怎么损失的,以后似乎要慎用了。 12-20 01:17
#define INTEG_FUNC(x) fabs(sin(x))

还是用了abs和sin函数
这个程序我回头用gcc试一下。
13楼2009-12-19 21:36:42
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

holmescn

金虫 (正式写手)


★ ★ ★ ★ ★
波不动(金币+5,VIP+0):感谢专家的实验结果!! 12-21 19:14
唉,又犯罪了,没有专心复习我的群论,开个小差做了一下实验。结果发出来吧。然后我再去看群论了。

1、把积分函数变成x*x,无优化,直接编译的:
gcc  2.976s
icc 0.249s

2、积分函数换回fabs(sin(x)),无优化:
gcc 10.402s
icc  2.044s

3、积分函数为x*x,无优化,去掉所有的printf。
gcc  2.968s
icc 0.001s

结果讨论:
一、glibc虽然很低效,但并不是影响gcc速度的主要因素。因为用sin后,icc同样运算时间提高了近10倍。而gcc只提高了不到4倍。
二、gcc有一个稳定的输入输出系统,而且和linux配合得很好,在除去所有输出函数后,并没有影响运算时间。同时提醒我们用icc编程时,尽量keep silence。不需要输出的时候就不要输出。
三、gcc的速度问题,可能源于它的内部架构,这一点有待到gcc的maillist里问一下。不过,如果你是要工作而不是学习C/C++语言的话,最好选用Inter C++ Compiler或PGI的Compiler。版权问题我就不多说了(这两天因为射手和QQ影音的版权问题,心里很不爽)。

结论是GCC不适合做大规模的数值计算。
14楼2009-12-21 16:05:04
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

波不动

木虫 (正式写手)


引用回帖:
Originally posted by holmescn at 2009-12-21 16:05:
唉,又犯罪了,没有专心复习我的群论,开个小差做了一下实验。结果发出来吧。然后我再去看群论了。

1、把积分函数变成x*x,无优化,直接编译的:
gcc  2.976s
icc 0.249s

2、积分函数换回fabs(sin(x)),无 ...

除了你说的这些,我发现用intel编译的程序计算的时候结果会有比较严重的精度损失,而我用gcc就不会。比较明显的就是我成图后,同一个程序,很多计算出来不应该为0的值,是一个很小的值,但是经过icc编译出来的程序计算出来就变成0了。而且我都不知道是哪里的问题。也可能是中间语句写的有问题。但是用gcc或者普通的cl就不会出现这个问题。
15楼2009-12-21 19:16:46
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

tjyl

金虫 (正式写手)


★ ★ ★ ★
波不动(金币+4,VIP+0):感谢专家的意见!! 12-21 20:59
内部函数库里的三角函数等对SSEx优化了的。
gcc虽然号称是支持了,但是差很多。
目前而言intel的是做的比较好的。
虽然gcc在这方面不行,但是在linux下编译的一般的软件还是不错,而且兼容性毕竟好吧。开源夸平台,支持10多种构架的CPU。
引用回帖:
Originally posted by holmescn at 2009-12-21 16:05:
唉,又犯罪了,没有专心复习我的群论,开个小差做了一下实验。结果发出来吧。然后我再去看群论了。

1、把积分函数变成x*x,无优化,直接编译的:
gcc  2.976s
icc 0.249s

2、积分函数换回fabs(sin(x)),无 ...

[ Last edited by tjyl on 2009-12-21 at 22:50 ]
16楼2009-12-21 20:49:32
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

holmescn

金虫 (正式写手)


★ ★
nono2009(金币+2,VIP+0):给个圣诞小礼包!祝新年心想事成! 12-24 22:15
我想原因就在于此了。因为要支持多CPU架构,所以一些中间代码优化可能不好做。只能牺牲性能来达到这一目标了。Intel则只针对X86架构,没有这些顾虑,得到充分优化的代码。
不过,只要规模不大,Gcc还是可以胜任的。比如几百几千的。虽然不够快,至少可以忍受。
17楼2009-12-24 11:43:59
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

★★★★★ 五星级,优秀推荐

★ ★
nono2009(金币+2,VIP+0):圣诞夜,辛苦了。去区务领红包吧。 12-24 22:15
波波厉害,学习了。
18楼2009-12-24 20:32:24
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖

holmescn

金虫 (正式写手)



senlia(金币+1,VIP+0):感谢专家同志参与 12-29 11:41
引用回帖:
Originally posted by 波不动 at 2009-12-21 19:16:


除了你说的这些,我发现用intel编译的程序计算的时候结果会有比较严重的精度损失,而我用gcc就不会。比较明显的就是我成图后,同一个程序,很多计算出来不应该为0的值,是一个很小的值,但是经过icc编译出来的 ...

这个回头再实验一下。是不是输出的问题呢?
19楼2009-12-29 11:09:52
已阅   回复此楼   关注TA 给TA发消息 送TA红花 TA的回帖
相关版块跳转 我要订阅楼主 波不动 的主题更新
☆ 无星级 ★ 一星级 ★★★ 三星级 ★★★★★ 五星级
普通表情 高级回复(可上传附件)
信息提示
请填处理意见