Chinaunix

标题: ［zz］高性能Linux Kernel项目—LinuxDNA ［性能真的提高 40%？］ [打印本页]

作者: prolj 时间: 2009-02-28 13:50
标题: ［zz］高性能Linux Kernel项目—LinuxDNA ［性能真的提高 40%？］
http://linux.solidot.org/article ... 313201&from=rss
旨在提供高Linux kernel性能的项目LinuxDNA，本月初成功实现用Intel C/C++编译器(ICC)编译了Linux kernel 2.6.22，不仅没有编译错误，而且完全可充当一个完整Linux系统的核心，开发者使用的Linux系统是基于Gentoo Linux。早期研究发现，用ICC编译Linux内核，在性能上可以提升40%。开发者以前使用的是ICC 8，目前已换到10.1和11版本。该项目的负责人Thaidog称：“ 编译一个新内核的所有指示都已公布在网站（虽然针对的是Gentoo，但其它任何发行版都适用）。任何有编译内核能力的人都可轻松完成。”他表示希望能维护一个与当前Linux内核并存的kernel源。现在的新内核对应的是2.6.22，因为.22版之后内核发生了一些变动，使得编译的难度加大了，但并非是不可能的。

40% 啊

看来 GCC 改进空间很大啊

的确有改进 GCC 寄存器分配这么个项目

作者: chenyx 时间: 2009-02-28 13:55
提高40%,的确很强

作者: cjaizss 时间: 2009-02-28 17:51
说实在的,我并不明白他的"性能提高40%"是什么意思

作者: jqbsx 时间: 2009-02-28 21:41
just info:

http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html
http://www.coyotegulch.com/reviews/linux_compilers/index.html (new)
http://www.coyotegulch.com/revie ... tel_gcc_bench2.html (old)

http://www.linuxjournal.com/cont ... x-intel-cc-compiler
(40% is mentioned here)

作者: prolj 时间: 2009-02-28 22:28

原帖由 jqbsx 于 2009-2-28 21:41 发表
just info:

http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html
http://www.coyotegulch.com/reviews/linux_compilers/index.html (new)
http://www.coyotegulch.com/reviews/intel_comp/intel_gcc ...

其实这个意义不是很大，因为你跑的 testcase 不一样得分也是不一样的。
客观的说，在 x86 上， ICC 做的很好（不过有人和 VS 比说 VS 编译出来的代码效率更高）， GCC的确有很大的改进空间（每个 Arch 都是，写出来高水平的 md 不容易，我现在体会到了），有人的文章说 CSDN 上说 ICC 将会取代 GCC 我就找啊，没找到，可能么？不记得 ORC 了？ FSF 不买帐谁都没辙！这个只能说 ICC 某些方面做的很好，然后 GCC 的开发人员去赶紧追赶。
不否认我也使用 OpenSolaris 去跑 SUN cc 了，可是在 OpenSolaris 上连 GCC 4 都无法编译（也许可以，太麻烦了）我就放弃了，意义不大，5 年之后 SUN cc 和 ICC 还有那个 ORC 对 GCC 还会有多少优势？10 年之后还会谁还会存在？

作者: OneThird 时间: 2009-02-28 22:38
据说使用GNU hash的工具链也能很大程度的提升性能。

作者: prolj 时间: 2009-03-01 20:18
标题: 回复 #6 OneThird 的帖子
Ubuntu 使用了 GNU hash，别的我就不关心了。
binutils 我还是算了，仅仅可以 port 就算了，不打算深究了。

作者: albcamus 时间: 2009-03-02 12:27
标题: 回复 #5 prolj 的帖子
> 其实这个意义不是很大，因为你跑的 testcase 不一样得分也是不一样的。

对，得看什么样的benchmark

>客观的说，在 x86 上， ICC 做的很好（不过有人和 VS 比说 VS 编译出来的代码效率更高）， GCC的确有很大的改进空间（每个 Arch 都是，写出来高水平的 md 不容易，我现在体会到了）

icc估计更多microarchitecture 级别的优化，而不是通用的优化。 Intel的icc开发工程师也有很多给gcc的x86 backend提补丁的

>不否认我也使用 OpenSolaris 去跑 SUN cc 了，可是在 OpenSolaris 上连 GCC 4 都无法编译（也许可以，太麻烦了）我就放弃了，意义不大，5 年之后 SUN cc 和 ICC 还有那个 ORC 对 GCC 还会有多少优势？10 年之后还会谁还会存在？

opensolarsi上编译gcc不麻烦，我就在用gcc 4.3.1呢。我的笔记，仅供参考：

44) 在Solaris/x86 上编译gcc

(注意，只针对4.0以及更新的gcc)

准备:

-> 安装libintl， sunfreeware上有；
-> 安装libmpfr和libgmp，用blastwave安装即可；

配置：

$ gtar jvxf gcc-4.3.1.tar.bz2
$ cd gcc-4.3.1
$ mkdir src
$ mv * src/
$ mkdir obj/ dst/
$ cd obj/

$ ../src/configure --prefix=/export/home/soft/gcc-4.3.1/dst/ --with-gnu-as \
--with-as=/usr/sfw/bin/gas --with-ld=/usr/ccs/bin/ld --without-gnu-ld
--enable-shared --enable-languages=c,c++ --with-gmp=/opt/csw/ --with-mpfr=/opt/csw/

/* 你可以直接：
   *
   * $ gmake
   * 来编译gcc；也可以：
   *
   * $ make bootstrap
   * 让gcc把编译过程分成3个stage，每一个stage的结果用来编译下一个stage，这是
   * 一个bootstraping的过程。如果硬盘空间不足，还想bootstrap，那就：
   *
   * $ gmake bootstrap-lean
   */
$ gmake bootstrap

/*{{{*/ 如果出现错误:
libcpp/下编译时找不到libintl_gettext等符号:
$ cd libcpp/
$ vi Makefile 给CFLAGS加上-L/usr/local/lib -lintl
$ gmake

//继续
$ cd ..
$ gmake

其他目录出现这个错误也是一样的办法。
/*}}}*/

[FYI] Solaris上是否可以用gcc和GNU ld来编译、连接程序？ gcc官方文档推荐使用SUN的link-editor，
      亦即/usr/ccs/bin/ld，而不是GNU ld。

   网上有人说，如果编译gcc时指定了--with-gnu-ld，那就可以把GNU ld的路径export到环境变量
   GCC_EXEC_PREFIX中去，gcc就可以使用GNU ld了。 (该方法尚待验证)

作者: cjaizss 时间: 2009-03-02 12:38

原帖由 albcamus 于 2009-3-2 12:27 发表
> 其实这个意义不是很大，因为你跑的 testcase 不一样得分也是不一样的。

对，得看什么样的benchmark

>客观的说，在 x86 上， ICC 做的很好（不过有人和 VS 比说 VS 编译出来的代码效率更高）， GCC的确有 ...

ICC是专用编译器，对于专门硬件的优化肯定是讲究的多的，专用和通用的差别还是很大的

作者: albcamus 时间: 2009-03-02 12:42

原帖由 cjaizss 于 2009-3-2 12:38 发表

ICC是专用编译器，对于专门硬件的优化肯定是讲究的多的，专用和通用的差别还是很大的

而且， icc之所以可以编译某些特定版本的kernel，也是因为它对gcc做了选项和语法上的全面兼容。

即使这样，也不是每个kernel版本都可以用icc编译的。

作者: cjaizss 时间: 2009-03-02 12:56

原帖由 albcamus 于 2009-3-2 12:42 发表

而且， icc之所以可以编译某些特定版本的kernel，也是因为它对gcc做了选项和语法上的全面兼容。

即使这样，也不是每个kernel版本都可以用icc编译的。

不过我怀疑不是icc去支持gcc语法、选项，而是去修改代码，包括C源码、makefile。

作者: prolj 时间: 2009-03-02 13:01

原帖由 albcamus 于 2009-3-2 12:27 发表
icc估计更多microarchitecture 级别的优化，而不是通用的优化。 Intel的icc开发工程师也有很多给gcc的x86 backend提补丁的

opensolarsi上编译gcc不麻烦，我就在用gcc 4.3.1呢。我的笔记，仅供参考：
44) 在Solaris/x86 上编译gcc
(注意，只针对4.0以及更新的gcc)
准备:

恩，这个我准备好好看看 intel 的那一卷优化手册。
我就是编译 libmpfr 和 libgmp 的时候出错了，没心思找那个原因。那个软件管理器里面没发现我才编译的，算了不关心了， KUbuntu 非常好用， Solaris 那优秀的 Kernel 和 Dtrace 对我一点吸引力都没有。
想跟你问一下，那个 OpenSolaris 的 ISO 上是 x86 和 x64 的内核都有，那么我装在 x64 上的时候，内核是 x64 的， app 呢？ SUN 这个 x86 的概念让我很浆糊。它在一个 ISO 里面有两套内核，不会也有两套 app 吧？
btw ，你现在在写东西？看你有好多笔记。
btw btw ，那个 md 文件的最详细描述在 internals 里面。

作者: prolj 时间: 2009-03-02 13:03
标题: 回复 #11 cjaizss 的帖子
icc 是购买的一个小公司的前端，好像还有几个商业编译器也都是买的那一家的，的确是号称“全面兼容 GCC ”当然后端兼容靠他们自己，那个卖前端的公司只能兼容那些 BT 的 GNU 扩展

据说有 GNU/Linux distro 用 ICC 编译的，但是我用过之后觉得一点都不快，反而很慢，这个不是说 ICC 不好，想必有其他原因。

[ 本帖最后由 prolj 于 2009-3-2 13:18 编辑 ]

作者: albcamus 时间: 2009-03-02 14:02
标题: 回复 #12 prolj 的帖子
几年前就记笔记了，总计有：

linux：

kernel

tips

programming

arch

acpi

hardware

english

solaris tips

solaris kernel

$ wc -l *
  1372 linux_acpi.txt
  2633 linux_arch.txt
420 linux_english.txt
572 linux_hardware.txt
  6902 linux_kernel.txt
  3150 linux_programming.txt
  6994 linux_tips.txt
806 solaris_kernel.txt
403 solaris_mdb.txt
  2496 solaris_tips.txt
25748 total

作者: system888net 时间: 2009-03-02 14:52
关注ls各位大拿的讨论.

作者: prolj 时间: 2009-03-02 15:33

原帖由 albcamus 于 2009-3-2 14:02 发表
几年前就记笔记了，总计有：

linux：

kernel

tips

programming

arch

acpi

hardware

english

solaris tips

solaris kernel

$ wc -l *
1372 linux_acpi.txt
2633 linux_ ...

提供匿名 svn 访问不？我们都学习学习你的积累

作者: albcamus 时间: 2009-03-02 23:05
标题: 回复 #16 prolj 的帖子
不够丢人的……

作者: emmoblin 时间: 2009-03-03 00:14
如期说改进gcc还不如就用集群编译来的更容易。提高可以更大。
对于一般用户，就算编译慢点也是无所谓的

作者: albcamus 时间: 2009-03-03 00:39
标题: 回复 #18 emmoblin 的帖子
这里说的不是编译速度，而是编译出来的结果，运行的速度。

作者: prolj 时间: 2009-03-03 00:46

原帖由 emmoblin 于 2009-3-3 00:14 发表
如期说改进gcc还不如就用集群编译来的更容易。提高可以更大。
对于一般用户，就算编译慢点也是无所谓的

有一个叫 distcc 的东西，但是对代码质量一点提高都没有
改进 GCC 不仅仅是提高编译速度，看现在的开发分支吧
Active Development Branches
General Infrastructure

var-tracking-assignments-branch
This branch aims at improving debug information by annotating assignments early in the compilation, and carrying over such annotations throughout optimization passes and representations. This branch is maintained by Alexandre Oliva. This branch is now tracking GCC 4.4; a separate 4.3 branch was maintained for some time, but there are no plans to maintain it any further.
struct-reorg-branch
This branch is for the development of structure reorganization optimizations, including field reordering, structure splitting for trees. These optimizations are profile information driven. This is a subbranch of tree-profiling. This branch is being maintained by Caroline Tice, Dale Johannesen, Kenneth Zadeck, Stuart Hastings, Mostafa Hagog.
autovect-branch
This branch is the successor to the lno-branch. The purpose of this branch is tree-level autovectorization work, and related work that the autovectorizer could use or benefit from (like data-dependence analysis, loop nest optimizations).
graphite-branch
The purpose of this branch is to develop an infrastructure for loop transforms using the polyhedral model.
lto
This branch aims to implement link-time optimization. Patches and discussion on this branch should be marked with the tag [lto] in the subject line.
boehms-gc
The goal of this branch is to test Boehm's GC feasibility as the garbage collector for GCC proper. This is a part of Google Summer of Code project, described in detail at http://gcc.gnu.org/wiki/Garbage_collection_tuning. The branch is maintained by Laurynas Biveinis.
ra-improvements
This branch aims to implement several improvements to the current register allocator. Examples include implenting a lower-triangular conflict matrix and register coalescing. It is hoped that these improvements will not only help the current allocator, but will be useful to the other register allocation projects such as RABLE and YARA. This branch will be merged with the dataflow-branch from time to time. The patches for this branch should be marked with the tag [ra-improvements] in the subject line. The branch is maintained by Peter Bergner.
ira
This branch contains the Integrated Register Allocator (IRA). It is based on work done on yara-branch. The latter is more of a research branch because one of its goals (removing reload) is too remote. The ira branch is focused to prepare some code for GCC mainline, hopefully in time for GCC 4.4. IRA still uses reload; it is called integrated because register coalescing and register live range splitting are done on-the-fly during coloring. The branch is maintained by Vladimir Makarov < vmakarov@redhat.com> and will be merged with mainline from time to time. Patches will be marked with the tag [ira] in the subject line.
ira-merge
This branch contains bug fixes for the Integrated Register Allocator (IRA). It is branched from trunk at revision 139590 when IRA was merged into trunk. It is used to track IRA related regressions. Only IRA fixes from trunk will be applied to this branch. Its goal is there should be no "make check" and performance regressions against trunk at revision 139589. The branch is maintained by H.J. Lu <hjl.tools@gmail.com> and Vladimir Makarov < vmakarov@redhat.com>.
sel-sched-branch
This branch contains the implementation of the selective scheduling approach. The goal of the branch is to provide more aggressive scheduler implementation with support for instruction cloning, register renaming, and forward substitution. The branch is maintained by Andrey Belevantsev <abel@ispras.ru> and Maxim Kuvyrkov < mkuvyrkov@ispras.ru> and will be regularly merged with mainline. Patches will be marked with the tag [sel-sched] in the subject line.
incremental-compiler
This branch contains change to turn GCC into an incremental compiler. The branch is maintained by Tom Tromey tromey@redhat.com. Patches for this branch should be marked with the tag [incremental] in the subject line.
gc-improv
This branch is for the development of garbage collector improvements. It is the successor to the boehm-gc branch, but without integration with Boehm's GC. The branch is maintained by Laurynas Biveinis.
milepost-branch
This branch is for GCC developments done in the Milepost project. (http://www.milepost.eu). The branch is maintained by Mircea Namolaru namolaru@il.ibm.com. Patches should be marked with the tag [mpost] in the subject line.
melt-branch
This branch is for a Middle End Lisp Translator branch, including both the plugin Lisp-like facility and static analyzers developped with it. This branch is maintained by Basile Starynkevitch basile@starynkevitch.net. Use the [MELT] tag for patches.
var-mappings-branch
This branch is for improving debug information based on tracking multiple variables per computed value. The branch is maintained by Richard Guenther and Michael Matz. Patches should be marked with the tag [varmap] in the subject line.
stack
This branch contains a new stack alignment framework to automatically align stack for local variables with alignment requirement. The branch is maintained by H.J. Lu <hjl.tools@gmail.com>, Joey Ye <joey.ye@intel.com> and Xuepeng Guo <xuepeng.guo@intel.com>. Patches should be marked with the tag [stack] in the subject line.
mem-ref
This branch is for lowering the GIMPLE IL for memory accesses to a flat representation. See the GCC wiki for a more detailed project description. The branch is maintained by Richard Guenther. Patches should be marked with the tag [mem-ref] in the subject line.
gcc-in-cxx
This branch is for converting GCC to be written in C++. Patches should be marked with the tag [gcc-in-cxx] in the subject line. This branch operates under the general GCC maintainership rules, except that any non-algorithmic maintainer is additionally permitted to approve changes which permit compilation with C++. The branch is maintained by Ian Lance Taylor.
thread-annotations
This branch contains the implementation of thread safety annotations and analysis (http://gcc.gnu.org/wiki/ThreadSafetyAnnotation). The branch is maintained by Le-Chun Wu. Patches and discussion on this branch should be marked with the tag [thread-annotations] in the subject line.
rtl-fud-branch
This branch is for the development of factored use-def chains as an SSA form for RTL. Patches should be marked with the tag [rtl-fud] in the subject line. The branch is maintained by Steven Bosscher and Kenneth Zadeck.
alias-improvements
This branch is for fixing the optimizers to efficiently work with a single alias symbol and for stripping the operand scanner, data-structures and alias computation according to this simplification. Patches should be marked with the tag [alias] in the subject line. The branch is maintained by Richard Guenther.
transactional-memory
This branch is for the development of transactional memory support for gcc. Patches for this branch should be marked [trans-mem] in the subject line. The branch is maintained by Richard Henderson.
c-4_5-branch
This branch is for C standards conformance improvements for GCC 4.5. Patches for this branch should be marked [4.5 C] in the subject line. The branch is maintained by Joseph Myers.
named-addr-spaces-branch
This branch is the development branch to add named address space support for architectures that have multiple address spaces. The CELL/spu architecture adds an __ea keyword to describe extended memory in the host chip address space instead of the local CELL/spu address space. The branch was created by Ben Elliston, and is now maintained by Michael Meissner.
dwarf4
This branch is for support of DWARF-4 features. DWARF-4 is currently under development, so changes on this branch will remain experimental until Version 4 is officially finalized.
plugins
This branch adds plugin functionality to GCC. See the plugins wiki page for details.

作者: ericqchem 时间: 2009-03-03 12:33

原帖由 prolj 于 2009-2-28 22:28 发表

意义不大，5 年之后 SUN cc 和 ICC 还有那个 ORC 对 GCC 还会有多少优势？10 年之后还会谁还会存在？

10年后谁会存在？gcc会，intel,pgi,absoft,pathscale,xlc,acc, sun cc都会，其实各种编译器主要应用在科学计算领域，只是icc兼容性太好了，所以现在有人用它编译通用软件。
不可否认gcc编译科学计算代码性能是最滥的。只有像龙芯集群那样的没有专用编译器的才会用。一般的hpc机群没有不买商业编译器的（当然也有用D版的,呵呵）。

作者: prolj 时间: 2009-03-03 12:50

原帖由 ericqchem 于 2009-3-3 12:33 发表
10年后谁会存在？gcc会，intel,pgi,absoft,pathscale,xlc,acc, sun cc都会，其实各种编译器主要应用在科学计算领域，只是icc兼容性太好了，所以现在有人用它编译通用软件。
不可否认gcc编译科学计算代码性能是最滥的。只有像龙芯集群那样的没有专用编译器的才会用。一般的hpc机群没有不买商业编译器的（当然也有用D版的,呵呵）。

absoft没有听说过，孤陋寡闻，小白了，呵呵。 IBM 的 xlc 肯定是有保障的， HP 的 acc ？ HP 手里死掉的东西还少么？ acc 很强么？何况这种拿不到代码编译器对我这样的爱好者有啥意义？就算拿到了代码，连 Linux 内核都编译不了有什么吸引力？搞一个 HPC 很容易，因为指标单一，你搞一个通用的试试看？软件匮乏就没人用，我是用 PC ，当然只考虑我这点需求，相信绝大多数人都和我一样是使用 PC ， HPC 对我们来说都是买不起的，呵呵。
不可否认目前 gcc 编译科学计算代码性能是比较滥的。 hpc 机群买得起商业编译器（盗版也是他们的事情）。龙芯？不了解，不谈这个。
科学计算市场很大么？非主流很好玩儿么？科学计算也是 Fortran 为主吧？ GFortran 是挺差劲的，连 PGI 都不如。这是目前的现状，5年之后呢？10年之后呢？现在我还什么都不敢说，不过这让我做了一个决定。

[ 本帖最后由 prolj 于 2009-3-3 13:00 编辑 ]

作者: xiegang112 时间: 2009-03-03 12:57
标题: 回复 #1 prolj 的帖子
Sun的cc和intel的icc评测下来，性能都比gcc强。这也可能它们都为专门的平台做了优化有关。

作者: system888net 时间: 2009-03-03 23:51

原帖由 emmoblin 于 2009-3-3 00:14 发表
如期说改进gcc还不如就用集群编译来的更容易。提高可以更大。
对于一般用户，就算编译慢点也是无所谓的

原帖由 albcamus 于 2009-3-3 00:39 发表
这里说的不是编译速度，而是编译出来的结果，运行的速度。

大拿们说了两个方面的东西:
1. 并行编译,提高了编译的速度.
2. 编译出能并行执行的程序,在多节点的环境下可以有效的提高程序的执行性能.

[ 本帖最后由 system888net 于 2009-3-3 23:52 编辑 ]

作者: system888net 时间: 2009-03-03 23:54
标题: 回复 #24 system888net 的帖子
而且这里都牵扯到粒度和分解模式的问题.

作者: mik 时间: 2009-03-03 23:59
所谓的 Linux DNA 项目就是使用 ICC 编译 linux kernel ???

作者: mik 时间: 2009-03-04 00:04
icc 编译器并没有什么好吹捧的

只不过是 intel 在 c/c++ 编译中生成非通用编译器（如 gcc）中不会使用的特定指令而已，一般是些 SSEx 指令。

如果，在 gcc 中使用嵌入汇编的形式使用这些特定指令，效果是一样的。

作者: prolj 时间: 2009-03-04 03:54

原帖由 mik 于 2009-3-4 00:04 发表
icc 编译器并没有什么好吹捧的

只不过是 intel 在 c/c++ 编译中生成非通用编译器（如 gcc）中不会使用的特定指令而已，一般是些 SSEx 指令。

如果，在 gcc 中使用嵌入汇编的形式使用这些特定指令，效果是 ...

正是如此！我了解了一下 ORC 的 port ，觉得和手工生成代码没什么区别。 ICC 优于 GCC 的地方主要是循环翻译成 SSE 。而没有说一种优化算法可以在一种编译器上实现却无法应用在另一个编译器上。

作者: BigMonkey 时间: 2009-03-04 10:05
gcc的性能优化参数有不少，例如
-marh
-mcpu
-m 64-bit
等等，请问测试的时候用了么？

以前听Intel的人说过，如果GCC选择合适的编译参数，那么ICC的编译出程序的性能优势并不大(<10%)。

作者: cjaizss 时间: 2009-03-04 10:21

原帖由 BigMonkey 于 2009-3-4 10:05 发表
gcc的性能优化参数有不少，例如
-marh
-mcpu
-m 64-bit
等等，请问测试的时候用了么？

以前听Intel的人说过，如果GCC选择合适的编译参数，那么ICC的编译出程序的性能优势并不大(

这倒也是,gcc还有那么多的编译参数,仔细比对的人可能不多。

作者: Magicloud 时间: 2009-03-04 11:08
一般gentoo的编译参数都比较优化，如果icc依然强劲，那只能是再次证明gcc有多烂。
不要说开源、兼容……之类的狗屁，只是把高级代码编译成机器码，不能发挥硬件应有性能的叫教学编译器！
按楼上诸位的逻辑，I和A花心思作那些sse之类的功能都是给科学计算用？因为我做普通用途，因为未来我可能改用非x86架构，所以我就没资格发挥硬件应有性能？而很明显的，这个错误的原因不在于那些可怜的c程序员。

作者: prolj 时间: 2009-03-04 11:26

原帖由 Magicloud 于 2009-3-4 11:08 发表
一般gentoo的编译参数都比较优化，如果icc依然强劲，那只能是再次证明gcc有多烂。
不要说开源、兼容……之类的狗屁，只是把高级代码编译成机器码，不能发挥硬件应有性能的叫教学编译器！
按楼上诸位的逻辑，I ...

你仔细看别人回帖了么？ Intel 的 compiler team 对这个我想比你我都熟悉吧？

原帖由 BigMonkey 于 2009-3-4 10:05 发表
gcc的性能优化参数有不少，例如
-marh
-mcpu
-m 64-bit
等等，请问测试的时候用了么？

以前听Intel的人说过，如果GCC选择合适的编译参数，那么ICC的编译出程序的性能优势并不大(

你了解任何一个编译器的后端么？
你知道 ORC 的效率比 GCC 好还是差么？你知道你所谓的“非教学”编译器的代码就一定很好？
你看过任何开源并且用于生产的编译器么？
你看见 GCC i386 的 port 里面有 mmx.md 和 sse.md 了么？
你跑了测试了么？对于指针满天飞的一般应用 GCC 比 ICC 差多少？
你知道怎么测寄存器压力么？

作者: Stout 时间: 2009-03-04 14:12

作者: OraBSD 时间: 2009-03-04 22:08

各位达人真牛啊!长见识了.

作者: siseniao 时间: 2009-03-07 21:08
其实就是软件和硬件结合的问题，当然在这方面硬件的制造商肯定有优势的，但是差距不会有40%那么夸张

作者: rawa9999 时间: 2009-03-08 14:03
GCC有多少种后端，ICC不过针对X86做了大量优化，要是编译mips上的代码就不行了吧，我偏爱GCC，自由软件的杰作。

作者: sharpshootor 时间: 2009-03-09 10:41
我好像有看过这个新闻，不是说内核部份性能提高40%，整体提高4%到8%左右吗

作者: prolj 时间: 2009-03-09 10:53

原帖由 rawa9999 于 2009-3-8 14:03 发表
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 ，抑或二者都做。谁再说开源编译器不行，用实际行动否定他。

作者: rawa9999 时间: 2009-03-09 19:22
针对一个处理器做好优化绝对不是一件简单的事情，java发展那末多年arm上在针对java字节码有了优化，自由软件可能不如商业软件做的細，但是技术上绝对没问题，自由软件是为理想而编程，某一方面可能逊色于商业软件，但是整体上不会比商业软件差，mips跟X86区别很大GCC能将一段源程序准确无误的生成两种平台的目标代码做的不比delphi差，甚至还好，除此之外还有众多交叉编译器。现在软件业已经到了社会化大分工的时代，将来任何的商业保守软件都会被无情淘汰，自由软件绝对不是山寨版。

作者: system888net 时间: 2009-03-09 21:03
大家说的有道理.

作者: hansion3406 时间: 2012-07-26 03:14
回不回呢，考虑再三，还是不回了吧。

作者: justmao945 时间: 2012-09-04 23:12
ICC是收费的吧？这种重要的部件不开源是不会被广泛用在linux上的？

作者: fly3ds 时间: 2013-10-04 15:35

prolj 发表于 2009-03-09 10:53
如果 Intel 找个人作 MIPS 支持， ICC 很快就可以支持 MIPS ，只是 MIPS 对 Intel 来讲是鸡肋还是鸡大腿呢 ...

吹牛谁不会啊。你还有改进GCC生成X86代码的计划，那我还有飞向人马座的计划呢。要是这么容易改，早就有人改好了。

作者: fly3ds 时间: 2013-10-04 15:36

Magicloud 发表于 2009-03-04 11:08
一般gentoo的编译参数都比较优化，如果icc依然强劲，那只能是再次证明gcc有多烂。
不要说开源、兼容……之 ...

没人求你用，不用赶紧滚蛋。

作者: fly3ds 时间: 2013-10-04 15:38

rawa9999 发表于 2009-03-08 14:03
GCC有多少种后端，ICC不过针对X86做了大量优化，要是编译mips上的代码就不行了吧，我偏爱GCC，自由软件的杰 ...

我以为ICC只能在X86机器上运行。在这文出现之前，我以为ICC只能在Windows上运行，没想到还有Linux版本的，哈哈。

作者: fly3ds 时间: 2013-10-04 15:43

rawa9999 发表于 2009-03-09 19:22
针对一个处理器做好优化绝对不是一件简单的事情，java发展那末多年arm上在针对java字节码有了优化，自由软件 ...

你也胡扯了。Delphi什么时候能”准确无误的生成两种平台“的代码？据我所知，Delphi只在Windows x86机器上出现过。Linux上的Delphi据说被称为Ky***，就是没人真的用过。

作者: fly3ds 时间: 2013-10-04 15:47
本帖最后由 fly3ds 于 2013-10-04 15:47 编辑

mik 发表于 2009-03-03 23:59
所谓的 Linux DNA 项目就是使用 ICC 编译 linux kernel ???

其实，能编译成功也算是个不小的奇迹。GCC在标准之外搞了很多自己的私货，Linux里夹杂着gcc的私活，要用ICC编译成功，肯定要做很多修改，是个不小的挑战，起码我是不敢想的。

作者: fly3ds 时间: 2013-10-04 15:50

cjaizss 发表于 2009-03-02 12:56
不过我怀疑不是icc去支持gcc语法、选项，而是去修改代码，包括C源码、makefile。

你是正确的，肯定是修改Linux核心代码以便让ICC编译通过。怎么可能是修改ICC适应GCC语法选项，那还叫ICC嘛。

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)