一般gentoo的编译参数都比较优化，如果icc依然强劲，那只能是再次证明gcc有多烂。
不要说开源、兼容……之类的狗屁，只是把高级代码编译成机器码，不能发挥硬件应有性能的叫教学编译器！
按楼上诸位的逻辑，I和A花心思作那些sse之类的功能都是给科学计算用？因为我做普通用途，因为未来我可能改用非x86架构，所以我就没资格发挥硬件应有性能？而很明显的，这个错误的原因不在于那些可怜的c程序员。
原帖由 Magicloud 于 2009-3-4 11:08 发表 http://linux.chinaunix.net/bbs/images/common/back.gif
一般gentoo的编译参数都比较优化，如果icc依然强劲，那只能是再次证明gcc有多烂。
不要说开源、兼容……之类的狗屁，只是把高级代码编译成机器码，不能发挥硬件应有性能的叫教学编译器！
按楼上诸位的逻辑，I ...
你仔细看别人回帖了么？ Intel 的 compiler team 对这个我想比你我都熟悉吧？
原帖由 BigMonkey 于 2009-3-4 10:05 发表 http://linux.chinaunix.net/bbs/images/common/back.gif
gcc的性能优化参数有不少，例如
-marh
-mcpu
-m 64-bit
等等，请问测试的时候用了么？
以前听Intel的人说过，如果GCC选择合适的编译参数，那么ICC的编译出程序的性能优势并不大(
你了解任何一个编译器的后端么？
你知道 ORC 的效率比 GCC 好还是差么？你知道你所谓的“非教学”编译器的代码就一定很好？
你看过任何开源并且用于生产的编译器么？
你看见 GCC i386 的 port 里面有 mmx.md 和 sse.md 了么？
你跑了测试了么？对于指针满天飞的一般应用 GCC 比 ICC 差多少？
你知道怎么测寄存器压力么？
:mrgreen: :mrgreen:
:mrgreen: :mrgreen: :mrgreen: :mrgreen:
各位达人真牛啊!长见识了.
其实就是软件和硬件结合的问题，当然在这方面硬件的制造商肯定有优势的，但是差距不会有40%那么夸张
GCC有多少种后端，ICC不过针对X86做了大量优化，要是编译mips上的代码就不行了吧，我偏爱GCC，自由软件的杰作。
我好像有看过这个新闻，不是说内核部份性能提高40%，整体提高4%到8%左右吗:em14:
原帖由 rawa9999 于 2009-3-8 14:03 发表 http://linux.chinaunix.net/bbs/images/common/back.gif
GCC有多少种后端，ICC不过针对X86做了大量优化，要是编译mips上的代码就不行了吧，我偏爱GCC，自由软件的杰作。
如果 Intel 找个人作 MIPS 支持， ICC 很快就可以支持 MIPS ，只是 MIPS 对 Intel 来讲是鸡肋还是鸡大腿呢？ Intel 曾经生产 ARM 的时候不知 ICC 支持 ARM 不，但是至少从 ICC 支持 x86 x64 和 IA64 上来看， port 决定不会比 GCC 复杂和繁琐（GCC port 是我见过最繁琐的）。
ICC 对 X86 的浮点优化很好，而且充分利用了 MMX 和 SSE 。看 Intel 的优化手册上，有好多针对芯片内部的优化，比如针对取指的优化，针对解码的优化。这个正如 mik 所说，没什么值得骄傲的，如果我是开源编译器的 commiter 我也不会考虑去做那么细的针对某个芯片内部的优化，考虑一下我改进一个算法，所付出的劳动和所带来的好处，还是在那里一个 cycle 一个 cycle 的有化芯片资源呢。
同样， GCC 的 X86 后端改进一下比 ICC 不会差到哪里去。我有改进 X86 代码生成质量的计划，只是还没有确定去改进 LLVM 还是 GCC ，抑或二者都做。谁再说开源编译器不行，用实际行动否定他。
针对一个处理器做好优化绝对不是一件简单的事情，java发展那末多年arm上在针对java字节码有了优化，自由软件可能不如商业软件做的細，但是技术上绝对没问题，自由软件是为理想而编程，某一方面可能逊色于商业软件，但是整体上不会比商业软件差，mips跟X86区别很大GCC能将一段源程序准确无误的生成两种平台的目标代码做的不比delphi差，甚至还好，除此之外还有众多交叉编译器。现在软件业已经到了社会化大分工的时代，将来任何的商业保守软件都会被无情淘汰，自由软件绝对不是山寨版。
大家说的有道理.