| 2009年9月29日
编译使用结果:
程序:
helight@Zhwen:test$ vim hello.c
#include <stdio.h>
int main()
{
printf("hello world\n");
return 0;
}
编译:
helight@Zhwen:test$gcc hello.c -o h_gcc
helight@Zhwen:test$icc hello.c -o h_icc
体积比较:
helight@Zhwen:test$ls -l
-rwxr-xr-x 1 helight helight 6558 2009-09-29 11:20 h_gcc
-rwxr-xr-x 1 helight helight 22178 2009-09-29 11:20 h_icc
-rwxr-xr-x 1 helight helight 7318 2009-09-29 11:15 test_gcc
-rwxr-xr-x 1 helight helight 22384 2009-09-29 11:15 test_icc
-rwxr-xr-x 1 helight helight 22267 2009-09-29 11:18 sec_icc
-rwxr-xr-x 1 helight helight 7522 2009-05-10 19:10 sec_gcc
上面还有其它的一些编译结果。结果标明icc编译后的程序体积较大。 运行速度比较:
helight@Zhwen:test$ time ./h_gcc
hello world
real 0m0.001s
user 0m0.000s
sys 0m0.000s
helight@Zhwen:test$
helight@Zhwen:test$ time ./h_icc
hello world
real 0m0.002s
user 0m0.000s
sys 0m0.004s
helight@Zhwen:test$
使用nm看其中的符号信息:
helight@Zhwen:test$ nm h_icc
0804a1c8 r _2__STRING.0
0804a1ec r _2__STRING.0
0804a920 r _2__STRING.1
。。。
0804b014 d _DYNAMIC
0804b0f8 d _GLOBAL_OFFSET_TABLE_
0804a1c4 R _IO_stdin_used
w _Jv_RegisterClasses
0804b004 d __CTOR_END__
....
08048380 t frame_dummy
080483a4 T main
U puts@@GLIBC_2.0
helight@Zhwen:test$
使用readelf看其它信息: 动态链接库信息:
helight@Zhwen:test$ readelf -d h_icc
Dynamic section at offset 0x3014 contains 23 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x00000001 (NEEDED) Shared library: [libdl.so.2]
。。。
helight@Zhwen:test$ readelf -d h_gcc
Dynamic section at offset 0x4b4 contains 21 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libc.so.6]
。。。
这里看出来icc会多引用库,而gcc就看起来比较简洁了!佛语说:依赖导致痛苦! 其它未发现太大的区别!!!
看来icc并没有传说中的那么神,但是我估计对于多核多线程的程序可能是做了一定的优化(注意只是可能,还没有测试验证), 但是就目前的小程序来说,icc还是很有问题的—编译体积大,运行时间也并没有多小!
所以还是放心使用gcc吧!
关注「黑光技术」,关注大数据+微服务